Így a nyár közepén min- 
denki könnyed nyaralásra, 
pihenésre vágyik nem pedig 
feszített tempójú munkára. 
Aki teheti vízparton vagy 
hegyek között mulatja ideje 
nagyrészét, akik viszont 

a városokban kénytelenek 
maradni, azoknak is valami 
kellemes időtöltés után kell 
nézniük. Ha éppen boron- 
gós az idő, vagy nagyon 
meleg van a CD mellék- 
letünkön lévő Slackware 
10.0-ás változat segíthet 





Csontos Gyula elütni az időt. Telepítése viszonylag 
(Csontos. GyulaOlinuxvilag.huj) egyszerű, bár nem veheti fel a ver- 


senyt az egérkattingatós, magyar- 
nyelvű, grafikus telepítőkkel, azért 
bátran vágjon bele mindenki. 

Akik esetleg a nyár hevében zenekar 
alapításra adták fejüket, vagy esetleg 


már régebb óta van egy csapatuk, 
azok bizonyára hasznosnak találják 
majd a 14.oldalon kezdődő vezér- 
fonalunkat, az Összefoglaló a Linux 
hangszerkesztőiről cikkünkben a leg- 
különfélébb hangfeldolgozó progra- 
mokat ismerhetjük meg, a Linuxos 
hangstúdió cikkünk pedig mindazok- 
hoz szól, akik szeretnének egy meg- 
bízható ámde alacsony költségveté- 
sű programokkal működő hangstú- 
diót építeni. 

A másik, mostanában igen szomorú 
téma a SPAM-ek elszaporodása. Ha 
valaki nem szűri a leveleit, akkor bi- 
zony előfordulhat, hogy mire a nyara- 
lásból hazaér, a postaládája szó szerint 
megtelik olyan levelekkel amiket nem 
is kért. Ennek a megfékezésére is 
ajánlunk egy pár mesterfogást. 


Kellemes időtöltést! 
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Programvadászat 


Slackware 10.0 


A Slackware az egyik legrégebbi 
linux disztribúció, immáron 12 éves 
múltra tekint vissza, szülőatyja Patric 
Volkerding. Egy jól használható, sta- 
bil, átgondolt rendszerről van szó. 
Aki kicsit komolyabban foglalkozott 
már linuxszal, annak bátran merem 
ajánlani, de igazából mindenki meg- 
próbálhatja telepíteni, nem egy 
ördöngősség. Lássuk mi is ezzel 

a helyzet. 


Első menet: telepítés 

A telepítés elkezdéséhez a szokásos 
CD-ről történő rendszerindítást kell 
engedélyezni a BIOS-ban. Ha ezzel 
megvagyunk helyezzük be a koron- 
got a meghajtóba és várjuk meg amíg 
megjelenik a boot: prompt. Itt külön- 
féle indulási paramétereket adhatunk 
át a rendszermagnak, általában elég, 
ha entert ütünk. Indulás közben kivá- 
laszthatjuk a használni kívánt billen- 
tyűzetkiosztást, majd a root szó begé- 
pelésével bejutunk a rendszerbe. 

A rendszer felhívja a figyelmünket, 
ha esetleg nem színes monitor előtt 
ülnénk mindenképpen adjuk ki 

a TERM-vt100 parancsot. Indítsuk el 

a setup programot, ez segít bennün- 
ket végig a telepítés rögös útján. A te- 
lepítő — szerintem egy zseniális prog- 
ram -— egyszerűen kezelhető, mindent 
tud amire szükségünk lehet. Kivá- 
laszthatjuk a kívánt partíciókat, a tele- 
pítendő csomagokat stb. A telepítési 
menet ugyan nem a legegyszerűbb, 
de magától értetődő, így erre nem 
térek ki. 


Második menet: Csomagkezelés 
Linux alatt, mint azt már megszokhat- 
tuk, több irányból is megközelíthejük 
a dolgokat, nincs ez másképpen 

a Slackware csomagkezelésével sem. 
Installpkg: A parancs szintakszisa na- 
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gyon egyszerű installpkg csomagnév 
A -warn kapcsolóval próbatelepítést 
végezhetünk, ilyenkor nem települ 

a csomag csak ellenőrzés történik, 
hogy valóban minden rendben lesz-e 
telepítés után. Ez akkor szerencsés, ha 
nem vagyunk teljesen biztosak a tele- 
pítendő csomagban, és abban, hogy 
az adott csomag telepítése nem okoz 
gondot a későbbiekben. A programok 
eltávolítását a removepkg csomagnév 
paranccsal tehetjük meg. 
Előfordulhat, hogy frissíteni szeret- 
nénk a rendszeren lévő csomagokat. 
Ebben segít a uugradepkg program. 
Ha az újabb és régebbi program- 
csomag neve megegyezik akkor 

a upgradepkg újcsomagnév parancs 

a nekünkvaló, ha különbözik a ne- 
vük akkor pedig használjuk az 
upgrade régicsomagnév újcsomagnév 
szintakszist. 

A SlackWare csomagok kitömörítésé- 
hez az explodepkg comagnév paran- 
csot használhatjuk. 

pkgtool: Aki nem szereti a parancs- 
sort, annak lehetősége van ezt az egy- 
szerű menüs programot használni. 
Ezt a programot is tartalmazza az 
alaprendszer. Azonnal felbukkan 

a menü, első feladatunk az lesz, hogy 
megadjuk a telepítendő csomag forrá- 











sát, jelenlegi könyvtár, 
más könyvtár stb.. 

Ha csomagot akarunk 
eltávolítani, akkor 
válasszuk a remove op- 
ciót. A következő lépés- 
ben válasszuk ki a tele- 
píteni/törölni kívánt 
csomagokat a szóköz 
billentyűvel. Ezután 

a program magától el- 
végzi a többit feladatot. 
A nagy kedvenc 
slapt-get: 

A Debianosok biztosan 
felkapták a fejüket erre a megneve- 
zésre, bizony-bizony ez egy APT-hez 
hasonló csomagkezelő Slackware alá. 
Ugyanúgy kereshetünk a program 
archívumokban (például 

a 59 htp:/www.linuxpackages.net 
csomagjai között) mint tesszük azt 

a debian rendszereken. 

A slapt-get install] csomagnév pa- 
ranccsal telepíthejük, a slapt-get 
remove csomagnév paranccsal pedig 
eltávolíthajuk a csomagokat. 


Egy ideális antivírus csomag 

A BitDefender AntiVírus csomag meg- 
található a CD virfilter könyvtárban. 
Ez a program a szokásos Anti-vírus 
védelem mellett Internet tartalom szű- 
rést és tűzfalas védelmet is nyújt, vál- 
lalati vagy otthoni környezetben. Ez- 
zel is védve a felhasználók adatait. 

A népszerű Webmin-hez is mellékel- 
nek egy modul aminek segítségével 
könnyedén beállíthatjuk a rendsze- 
rünk védelmét. 


Csontos Gyula 

(Csontos. Gyulaolinuxvilag.hu) 
A Linuxvilág szakmai és 
CD-szerkesztője. Szabadide- 
jében szívesen mászik 
hegyet és kerékpározik. 














Középút: Tenon 
A Wiscore cég Tenon névvel újabb, el- 
sősorban otthoni használatra szánt, vi- 
szonylag kevés szolgáltatást nyújtó, 
de kedvező árú linuxos kiszolgálót 
mutatott be. A webes felületen keresz- 
tül kezelhető Tenon levél-, web- és 
FTP-kiszolgálóként használható, to- 
vábbá forgalomirányítóként és tűzfal- 
ként is szolgál. Erőssége, hogy operá- 
ciós rendszere csak 
olvasható adathor- 
Beíjés dozóról indul, így 
könnyedén visszaál- 
lítható eredeti álla- 
potába. Gyengesége, hogy helyi fájl- 
vagy nyomtatókiszolgálóként nem 
használható, már csak azért sem, mert 
merevlemezes meghajtóval nem ren- 
delkezik. A leveleket, weblapokat 
CompactFlash kártyán tárolja, az alap- 
kiépítés szerinti kártya 128 MB-os, de 
nagyobb kártyát is vásárolhatunk bele. 
A készülékhez ingyenes frissítési szol- 
gáltatás jár, tehát a belső programhoz 
készülő biztonsági javításokat és 
egyéb frissítéseket mindenki szabadon 
beszerezheti hozzá. 
2 www.wiscore.com/en US 


Intel BIOS-utód szabadon 
Az Intel bejelentette, hogy következő 
generációs BIOS programjának — pon- 
tosabban annak a belső programnak, 
mely a BIOS utóda, egyben az 
Extensible Firmware 
j Interface egyfajta megvaló- 
intel. sítása lesz — alapja CPL 
(Common Public License) 
szerződési feltételekkel lesz hozzáfér- 
hető. A BIOS több mint 20 éve biztosít- 
ja a személyi számítógépek működésé- 
hez szükséges alapeljárásokat, a kor 
azonban túlhaladt rajta, sokkal több és 
újszerűbb szolgáltatást várnánk el tőle. 
Az újfajta belső program - ilyet egyéb- 
ként a Phoenix is fejleszt már egy ideje 
— felügyelhetőség és szervizelhetőség 
terén egyaránt olyan lehetőségeket kí- 
nál majd, amelyek megvalósítása a je- 
lenlegi BIOS-okkal gyakorlatilag lehe- 
tetlen volna. 
Az Intel egy illesztőprogram fejlesztői 
készletet is kínál majd a belső prog- 
ramhoz, ezzel is a különféle gyártók 
termékei közötti együttműködést kí- 
vánja javítani. A kód a CollabNet köz- 
reműködésével lesz elérhető. 
2 wwwiintel.com/technology/ 
framework 
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Játékkonzol-mindenes 

A Sony először mutatta be PSP játék- 
konzoljának mintapéldányát. A kon- 
zolt ugyan már korábban bejelentet- 
ték, látni azonban még senki nem lát- 
ta, és a nagyközönség számára várha- 
tóan csak év végén vagy jövőre lesz 
elérhető. A PSP-t, mely a Sony szerint 
a 21. század mobil eszköze, elsősorban 
a 18-34 éves korosztálynak szánják, de 
később a fiatalabb generációt is meg 
szeretnék hódítani vele. A készülék 
170 x 74 x 23 mm-es, súlya 260 gramm. 
Belsejében egy legfeljebb 333 MHz 
órajelű PSP processzor és 32 MB me- 
mória rejtőzik. 16:9 képarányú kijelző- 
je 4,.37-os, 480x272 képpont és 167 
millió szín megjelenítésére képes, 
fényereje 200 dc/m?. A PSP rendelke- 
zik egy UMD olvasóval is, ebbe egyol- 
dalas, kétrétegű, 1.8 GB kapacitású op- 
tikai lemezek helyezhetők; továbbá 
kapott egy 802.11b típusú vezeték nél- 
küli hálózati csatolót, USB csatlakozót, 
infravörös kaput és Memory Stick 
PRO Duo aljzatot. Kiegészítő jelleggel 
számos eszköz megvásárolható lesz 
hozzá, többek közt kamera és GPS ve- 
vő is, amiből egyértelműen arra lehet 
következtetni, hogy sokkal több lesz 
egy korszerű videojátéknál. 

3 www.playstation.com 


Otopia telefonra 

A Trolltech elkészült tavaly októberben 
bejelentett mobiltelefonos alkalmazás- 
készletével, a palmtopokon megismert 
szolgáltatásokat nyújtó Otopia Phone 
Editionnel. Az alkalmazáskészlet gya- 
korlatilag minden, a Linux futtatására 
alkalmas processzort támogat, a billen- 
tyűzettel és az érintőképernyővel ellá- 
tott készülékeken egyaránt használha- 
tó. Működéséhez legalább 8 MB Flash 
ROM és 16 MB RAM, valamint 16 
szürkeárnyalat és 176x208 képpont 
megjelenítésére képes kijelző szüksé- 
ges. A Otopia Phone Edition öt össze- 
tevőből áll össze, ezek a telefonos ke- 
zelőfelület, a személyi adatkezelő al- 
kalmazások, a telefonos alaprendszer, 
a szinkronizáló megoldás és a fejlesz- 
tői környezet. 

Piackutatók szerint néhány éven belül 
a telefoneladások egynegyedét az 
okostelefonok teszik majd ki, és ezek 
között a Linux olyan szerepet játszhat, 
mint az asztali számítógépek körében 
annak idején a DOS. 

3 wwwi.trolltech.com 
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Ki Hír-lelő 





Elektronikus is, meg nem is 

Jie Chen, egy 18 éves fiatalember 
nyerte az Amerikában megrendezett 
második nemzetközi e-zongoraver- 
senyt. A verseny különlegessége, hogy 
a darabokat Yamaha Disklavier zongo- 
rákon játsszák. 

A Yamaha ezen 
speciális zongorái 
a hagyományos és 
a digitális megol- 
dásokat ötvözik. 
Egyszerre szolgál- 
nak normál zon- 
goraként, digitális 
felvételre képes 
MIDI billentyűzet- 
ként és számító- 
gépről vezérelhető gépzongoraként. 
A Disklavier zongorákon lejátszott da- 
rabokat rögzítés után tökéletesen — 

a zongora húrjainak és kalapácsainak 
segítségével, nem szintetizátoros meg- 
oldással — rekonstruálni lehet, akár 
egy interneten keresztül elküldött fájl 
alapján is. Sőt, a versenyre az előzetes 
meghallgatások után meghívott mű- 
vészeket is így választották ki. Mind- 
egyik induló a területi próbákon mu- 
tatta be tudását, amelyet mozgókép és 
adatfájl formájában egyaránt rögzítet- 
tek. A zsűri egy ugyanilyen zongorán 
játszotta vissza a darabokat, és az így 
hallottak-látottak alapján jelölte ki 

a végső versenye való részvételre ér- 
demeseket. A meghallgatások és a ver- 
seny anyagait a rendezvény holnapjá- 
ról bárki letöltheti. 

3 www.piano-e-competition.com 


Rendrakás 

Linus Torvalds és a Linux 
rendszermagfejlesztő csoport egy hoz- 
zájárulás-követő rendszer üzembe állí- 
tása mellett döntött. A továbbiakban 

a fejlesztőknek digitálisan alá kell 
majd írniuk foltjaikat, ezzel igazolva 
azt a jogukat, hogy az adott kódrész- 
lettel hozzájáruljanak a rendszermag 
fejlődéséhez. Minden fejlesztőnek nyi- 
latkoznia kell arról, hogy a kódot vagy 
maga készítette, vagy jogszerűen vette 
át máshonnan, vagy harmadik féltől 
az előbbi feltételek valamelyike mel- 
lett szerezte be, és változatlanul adja 
tovább. A rendszer révén nemcsak 

a foltok, és egyúttal a rendszermag 
jogtisztaságát lehet majd garantálni, 
de a fejlesztők kilétét és a hozzájárulá- 
sokat is jobban követni lehet. 
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Jövőre a füstjelek jönnek 

A Nokia 3220 jelzésű mobiltelefon — 
pontosabban, követve a Nokia szó- 
használatát, kameratelefon — újabb 
kommunikációs módszerrel ismertet 
meg bennünket. 
A 3220 nagy új- 
donsága az 

a fedlap, amely 
képes feliratokat 
a levegőbe vetíte- 
ni, miközben 

a telefonnal ha- 
donászunk. 

A fényüzenetnek keresztelt szolgálta- 
tást például zsúfolt helyiségekben le- 
het majd jól használni, ahol mit sem 
ér az üvöltözés, a mutogatás pedig fél- 
reérthető - elég lesz tehát beírni a te- 
lefonba, majd megfelelő mozdulattal 
lejátszani az üzenetünket. A telefon 
érzékeli a gyorsulást, ennek megfele- 
lően jeleníti meg a szükséges karakte- 
reket, amelyek összeolvasva a kívánt 
szöveget alkotják. 

A telefon további érdekessége, hogy 
kézben tartható botkormányként is 
használható, így a lövöldözős, mász- 
kálós játékokat — a készülékhez alap- 
esetben két ilyen jár — teljesen újfajta 
módon futtathatjuk majd rajta. 
Kézenfekvő módon, az előlap fényei- 
nek segítségével a 3220 képes arra is, 
hogy a hívásokat és üzeneteket fé- 
nyekkel jelezze, akár a csengőhangok 
ritmusára villogva. A VGA felbontású 
kamera, a változatos testreszabási le- 
hetőségek és a háromsávos működés 
már csak megkoronázza mindezt. 

A Nokia 3220 hamarosan kapható 
lesz, ára 250 euró körül várható. 

2 www.nokia.com 


Nokia — Mozilla együttműködés 

A Nokia és a Mozilla Foundation 
együttműködésével egy új böngésző- 
program fejlesztése indult meg. 

A Nokia támogatásával Minimo név 
alatt, amint az sejthető, mobiltelefo- 
nokra fog készülni egy nyílt forrású 
böngésző. Az évek óta futó Mozilla 
böngészőkre az utóbbi időben elég 
sok panasz volt, a Nokia megjelenésé- 
nek és persze pénzének köszönhetően 
remélhetőleg kicsit felpezsdül az élet a 
tervezet környékén. A tényleges üzleti 
megállapodásról részleteket nem lehet 
tudni, a felek csak annyit árultak el, 
hogy a Nokia aktív szerepet vállal 

a nyílt forrású közösségben. Az alapít- 





ványnál remélik, hogy a közeljövőben 
sikerül további megállapodásokat is 
összehozni, amelyek alapján prog- 
ramjukat különféle területek, alkal- 
mazások igényeihez igazítják, majd 

a létrejövő megoldásokat nyílt forrás- 
sal teszik elérhetővé — egyébként 1998- 
ban a Mozilla.org pontosan azért jött 
létre, hogy félig-meddig kereskedelmi 
jellegű, mégis nyílt forrású fejlesztési 
modellt kövessen. Talán végre sikerrel. 


3D asztali monitor 

A Sharp LL-151D jelöléssel egy új, 
157-os, színes, különleges szemüveg 
használata nélkül is 3D megjelenítésre 
képes LCD-monitort mutatott be. 

A kijelző 2D módban is használható, 





ekkor felbontása 1024x768 képpont, 
3D módban viszont vízszintes fel- 
bontása megfeleződik. A kijelző a két 
szem számára eltérő képet állít elő, 

a különleges szemüveg elhagyásával 
használata is kényelmes; egyetlen 
hátránya, hogy a 3D kép csak a mo- 
nitorral pontosan szembe nézve 
élvezhető. A Sharpnak már eddig is 
voltak hasonló kijelzői, ám azok csak 
hordozható gépekben jelentek meg, 
asztali monitorként nem. Az alkalma- 
zási területek köre rendkívül széles, 
tudományos, mérnöki feladatokra és 
persze játékra egyaránt jól lehet 
használni az új monitort, amelyből 

a cég hamarosan nagyobb változa- 
tokat is meg kíván jelentetni. 

2 wwwi.sharp.com 


Medgyesi Zoltán 
(mzerettesoft.hu) 

A Linuxvilág hírszerkesztője. 
Szabadidejét legszívesebben 
a barátnőjével tölti, szeret 
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Mi újság a rendszermag fejlesztése körül? 





A BIOS a számítógép egyik legbarátságtalanabb ré- 
sze. A forráskód általában titkos, frissítések pedig 
szinte nem is léteznek. A modern operációs rend- 
szerek megpróbálják amint lehet maguk mögött tud- 
ni a BIOS-t, és saját hasonló feladatú kezelőfelületü- 
ket használják. 
Néha a BIOS hibák miatt a OS fejlesztők kénytele- 
nek lépéseket tenni annak kijavítására. Az M6805 
eMachines esetében is éppen mostanában történt 
ilyesmi. A BIOS nem volt képes felismerni a CPU 
frissítést és az eredeti CPU által használt CPU se- 
bességet és voltértékeket jelentette. Tony Lindgren 
készített egy Linux rendszermag foltot, amely bizo- 
nyos érvényességi teszteket végez ezeken a gépe- 
ken, és ha szükséges kijavítja a BIOS által vissza- 
adott értékeket. 





Benjamin Herrenschmidt az Open Firmware sysís 
csatolófelületén dolgozik, hogy a PPC és PPC64 
rendszereknek teljes Open Firmware támogatást 
biztosítson. Jól példázza a Linuxos fejlesztési stílust, 
hogy amint Benjamin bemutatta munkáját, több ter- 
vezési kérdést is alapos vizsgálat alá vettek. Például, 
az Open Firmware adatot ő a PCI eszközök adatai- 
nak részeként szerette volna kiadni, ami könnyen za- 
vart okozhatna. Most akkor az összes sín és vala- 
mennyi különféle firmware kezdje el egymás adatait 
tárolni? És vajon a rendszer melyik más része sze- 
retné majd máshol is ábrázolni az adatokat? Linus 
Torvalds azt javasolta, hogy a különféle szemponto- 
kat külön vizsgáljuk, ezért az Open Firmware adato- 
kat — még ha PCI eszközökkel foglalkozik is -, az 
Open Firmware alkönyvtárba kell helyezni. 


Dipankar Sarma készített egy API függvényt mely- 
nek segítségével bizonyos ReiserFS (és egyéb) kó- 
dot le lehet majd tisztázni. Az rcu barrierO) nevű 
függvény megvárja míg az összes RCU visszahívás 
befejeződik. Az RCU azaz Read Copy Update (Olva- 
sás Másolás Frissítés) annak a zárolási mechaniz- 
musnak a neve, amely segítségével az OS alacsony 
költséggel képes elérni a több processzor között 
megosztott adatterületeket. Korábban a ReiserFS- 
nek saját logikát kellett alkalmazni, e képesség szín- 
lelésére. Nikita Danilov a ReiserFS csapatból már 
régóta vágyott egy ilyen API kódra. Amint ezt elfo- 
gadják a fő fában, a Reiser gárdája végre kihajíthat 
egy halom ronda kódot. 


A Linux 2.0.40 (moha-lepte teknőc — 7he Moss- 
Covered Tortoise — kódnevű) változatának megjelen- 
tetésével, David Weinehall megmutatta, hogy szán- 
dékában áll folytatni az ősi 2.0-ás sorozat karbantar- 
tását. A 2.0.40-ben többek közt kijavított számos 
biztonsági lyukat és fájlrendszer károsodási problé- 
mát. Bejelentésében David leszögezte, hogy semmi- 


lyen új képesség nem kerül a 2.0-ás sorozatba. Mint 
mondotta, A jelenlegi rendszermagok képességeit 
kereső felhasználóknak, a 2.4 vagy 2.6-os fára kell 
frissíteniük. Néhány rendszernek problémákat okoz- 
hat az átállás, ilyenek például a mindig 2.0-ás rend- 
szermagot futtató aktív kiszolgálók, amelyeket bár- 
milyen későbbi rendszermaghoz teljesen újra kéne 
tervezni. Ennek ellenére úgy tűnik nem igazán alkal- 
mas a jelenleginél simább frissítési módszert kialakí- 
tani, tekintve, hogy a páros számú rendszermagok- 
nak a stabilitásra kell törekedniük. 


Max Asbock mostanában készítette el az IBM 
xSeries RSA kiszolgálóprocesszorának támogatását. 
Az ibmasm nevű meghajtó felületet biztosít a fel- 
használói térből érkező parancsoknak, várakozik az 
eseményekre és kezeli a távoli videó képességeket. 
Az egyetlen gubanc a jelenlegi megoldással, hogy 
Max csatolófelülete teljesen egyedi a Linux világá- 
ban. Bár a meghajtó rendszereléréssel foglalkozik, 

a sysfs ,egy fájl, egy érték" módszerének alkalma- 
zására Max nem lát semmilyen lehetőséget. A meg- 
hajtó a karakteres eszköz kategóriába sem préselhe- 
tő be egykönnyen, ezért a rendszermag forrás-fa 
/drivers/misc könyvtárába került. Figyelembe véve 
ezeket az eltéréseket, a meghajtó valószínúleg né- 
hány változtatáson megy majd keresztül, mielőtt be- 
kerülhetne a helyes rendszermagváltozatba. De még 
ha gyorsan el is fogadják, beletelhet egy kis időbe, 
mire a csatolófelület megállapodik, ahogy a kedvelt 
Linuxos helyek magukévá teszik. 


Gerd Knorr írt egy meghajtót, amely ugyan felhasz- 
nálói szemmel nézve önmagában semmilyen látvá- 
nyos dolgot nem mutat, viszont segít a többi meg- 
hajtónak az infravörös távirányító eszközök kezelésé- 
ben. Az olyan meghajtók, mint a saa7134 és a bttv 
mostantól tiszta kóddal a szabványos Linux beme- 
neti réteget használhatják az eléréséhez. Érdekes 
csavar a dologban, hogy az alap Linux modulkezelő 
kód megváltozott a 2.5-ös időkben, Gerd mégis 
tartotta magát a régi csatolófelülethez, holott ez 

a meghajtó a 2.6-hoz készült. Ennek az az oka, hogy 
szeretné, ha kódja 2.4 és 2.6 alatt is lefordulna, 

a 2.4 pedig nem támogat néhány 2.6-ban megjelent 
funkciót. Rusty Russell, a 2.5 alatt bekövetkezett 
modul újratervezésért leginkább felelős fejlesztő, 
igen aktívnak tűnik az ilyesfajta problémák kezelésé- 
ben és kijelentette, hogy együttműködési funkciókat 
fog készíteni a 2.4-hez amelyek lehetővé teszik, 
hogy a 2.6 szerkezetek mindkét rendszermag válto- 
zaton helyesen leforduljanak. 


Zack Brown 


Linux Journal 2004. június, 122. szám 
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nA proxy marad proxy" 


Beszélgetés Daczi Lászlóval, az MLDP születésnapjának alkalmából. 


0 Kiskapu Kft. Minden jog fenntartva 


— Sok Linux-közeli csoport van, milyen céllal alakult a Magyar összes, könyvutalvány és plüsspingvin is szerepel a cso- 
Linux Dokumentációs Projekt (MLDDP) és kik alakították? magban, melyeket Horváth Albert, Völgyi Péter és Szalai 

— 2001 végén 2002 elején angol nyelvtudásom fejleszté- Ferenc kapnak. 
se céljából lefordítottam a Linux -- XFS HOGYANTt, ezt 
szerettem volna közzétenni egy már létező, linuxos — Milyen rövid- és hosszútávú terveitek vannak? 
doksikat tartalmazó webhelyen, de nem kaptam vissza- — — Rövid távon egy fordítást segítő (lin/win) kliens készítése 
jelzést. Egy ideig próbálkoztam, aztán meguntam. Mivel a cél, amelyen jelenleg diplomamunka keretében dolgo- 
ekkor már a fordítás során szerzett tapasztalataimat is zom. Ez remélhetőleg egy nemzetközi nyílt forráskódú 
szerettem volna megosztani másokkal, egy önálló pro- projektté növi ki magát. Hosszú távon az oktatási intéz- 
jekt indítása tűnt célravezetőnek. Egyedül nehéz életben ményekkel való együttműködés a cél, így a rendelkezésre 
tartani egy ilyen vállalkozást, ezért társakat kerestem. álló (emberi) erőforrások megsokszorozódhatnak. 
Az FSEhu Alapítványt megelőző baráti társaság ekkori- 
ban vált ismertté, és mivel úgy láttam, hogy nekik nem — Kiknek a segítségét várjátok? 
csak a szájuk jár, ezért hozzájuk csatlakoztam. A Magyar  — A fordítandó dokumentumok kiválasztásához informatikai 
LDP így az FSE.hu Alapítvány keretében, egy önálló pro- szakemberek segítségére van szükség, mivel nem területen 
jektként valósult meg. Célja a The Linux Documentation tudom felmérni az információ aktualitását. A fordításhoz an- 
Project által készített és karbantartott dokumentumok golul tudó, és a szaknyelvet ismerő emberekre van szüksé- 
magyarítása. E mellett a fordítások karbantartását is günk. A honlap csinosításában webdizájnerek segíthetnek, 
lényegesnek tartjuk, ezáltal a befektetett munka nem jó minőségű embléma elkészítéséhez pedig számítógépes is- 
vész kárba. meretekkel rendelkező grafikusok jelentkezését várjuk. 

— Az elmúlt két év alatt milyen nagy mérföldkövek voltak? — A minap nálunk járt Richard Stallman, aki egy kérdésre azt nyi- 

— Az első a projekt indulása, ez tulajdonképp a közösség latkozta, hogy szerinte a programok honosítása illetve általában 
tesztelése volt (2002 ápr. — 2002. júl.). Már akezdetekbenis a fordítás elveszi az erőforrásokat a fejlesztéstől. Neked, mint 
rátaláltunk (vagy inkább fordítva) egy-két aktív emberre, a fordítási munkák koordinátorának mi erről a véleményed? 
akik segítettek az alapok lerakásában (fordítás, sgml — Természetesen tiszteletben tartom a véleményét, szerin- 
konvertálás stb.). A második, az ismertség megteremtése, tem viszont aki fordítani akar az úgyis fordítani fog, aki 
a fejlődés és túlélés szempontjából is fontos volt (2002. meg programozni akar, az programozni fog. Én időnként 
aug. — 2003. júl.). Elkészült egy szógyűjtemény, Fordítás- fordítok, amikor pedig megcsömörlök tőle akkor progra- 
HOGYAN, működött a levelezőlista, és a hírportálokon is mozok. Mindenki úgy éli ki a tehetségét, ahogy tudja. Az 
rendszeresen megjelentünk. Az első évfordulót követően MLDP nem egy , kényszerprojekt" , az önkéntesek a nekik 
(2003. aug. — 2004. jún.) elkészült egy Debian csomag, megfelelő (vagy annak látszó) feladatot vállalják el. 
amely jelentősen megkönnyíti az sgml/xml forrás konver- 
tálását, bővült az önkéntesek tábora, van két-három — Minek az alapján választjátok ki, hogy mi legyen lefordítva, 
visszatérő ember. Megkezdődött a kapcsolatfelvétel a Sze- és mi ne? 
gedi Tudományegyetemmel, ahol a nyílt forráskódú szoft-  — Alapvetően én választom ki a fordításra ajánlott doku- 
verfejlesztés a tantervben is szerepel. mentumokat. Ez azt jelenti, hogy bárki választhat a TLDP 

dokumentumok közül egy neki tetszőt, legfeljebb meg- 

— A csoport aktív tagjai milyen ellenszolgáltatásért, vagy remélt próbálom lebeszélni róla. A saját kiválasztási szempontja- 
céllal vesznek részt a közös munkában? im a következők: 

— Pénzbeli ellenszolgáltatás nincs, a legtöbben ismereteik e lehetőleg használható információk legyenek benne, 
bővítése, vagy vizsgajegy megszerzése céljából segítenek. ne legyen elavult 
Mindezek mellett évente 3 önkéntes munkáját jutalmaz- e lehetőleg széles körben felhasználható legyen, ne túl 
zuk, a lehetőségeink szerint. Idén a Kiskapu Kft. jóvoltá- speciális témáról szóljon (például egy adott márkájú és 
ból - a szokásos oklevélen és pólón túl — Linuxvilág típusú alaplap beüzemeléséről; ez létező példa) 
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e mindig legyen a kínálatban kezdőknek való rövidebb 
dokumentum 


Mivel nem mindig tudom megítélni egy dokumentum 
használhatóságát, ezért (kihasználva a projekt nyíltságát) 
ebben is az önkéntesekre támaszkodok. A Fordítás 
HOGYANban erről külön fejezet van. 


— A számítástechnikában különös jelentősége van a magyar szak- 
nyelv fejlesztésének. Ti mennyire tartjátok ezt fontosnak, illetve 
hogyan gondoskodtok a különböző fordítóktól származó anyagok 
nyelvi egységesítéséről? 

— Fontosnak tartjuk. Lefordítjuk azt aminek van értelmes, 
érthető és (viszonylag) pontos magyar megfelelője. Példá- 
ul a kernel az rendszermag, viszont a proxy az marad 
proxy, mivel jelenleg nincs rá megfelelő magyar szó vagy 
kifejezés. A nyelvi egységet a szógyűjtemény (lásd Fordí- 
tás HOGYAN) illetve a lektorok biztosítják. 


— Kiválthatják-e az általatok magyarra fordított és ingyenesen el- 
érhető dokumentumok a magyar nyelvű szakkönyveket? 

— Véleményem szerint nem, viszont kellő alapot nyújthat- 
nak azok megértéséhez, illetve kiegészíthetik azokat. 
Egyes HOGYANOokban vannak is hivatkozások nyomta- 
tott dokumentációra. 


— Mit gondolsz, mikor éri el az MLDP a , repülési magasságot", 
vagyis mikor következik be az, hogy aki fordítani akar, annak na- 
gyítóval kell keresgélnie? 


— Ez nagyon elméleti kérdés, nem tudom. Elméletileg soha, 
ugyanis a dokumentációkat frissíteni is kell, márpedig minél 
több van, annál gyakrabban és többet kell dolgozni rajta. 


— Mit gondolsz, a jó minőségű magyar dokumentáció megléte 
mennyiben fogja előmozdítani a Linux elterjedését, gondolok itt 
az állami szférára, illetve az oktatásra? 

— Szerintem ez kulcskérdés. Bár a számítástechnikában 
alapvető követelmény volt az angol nyelvtudás, mára ez 
megváltozott. Sajnos Magyarországon eléggé csehül ál- 
lunk a nyelvtudással, és mivel a számítástechnikával vala- 
milyen szinten foglalkozók száma megnőtt, ezért az ango- 
lul értők aránya is megváltozott a ,szakmában" . 
Egyébként is, mindenki az anyanyelvén szóló információt 
képes a legjobban magába szívni. 


— Bár egyesek szerint Közép-Európában a mi hálózati infrastruk- 
túránk a legfejlettebb, egyes környező országokban a Linux na- 
gyobb elterjedtségnek örvend, mint nálunk. Mennyire függhet 
ez össze a nemzeti nyelvre fordított dokumentumokkal? 

— Ezt igazából nem tudom megítélni, mivel nem ismerem 
a környező országok helyzetét a nemzeti nyelvre fordított 
dokumentumok tekintetében. Valószínűleg van valamilyen 
összefüggés, de biztos nem csak ettől függ. Nagyobb és 
maradandó előnyös változáshoz szerintem állami szerep- 
vállalásra van szükség. Mivel azonban a magyar politikai 
élet olyan, amilyen, ezért jelenleg erre nem látok reményt. 


Büki András -— Szy György 
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A Linux és a protonok 


Hogyan zajlik az élet a világ legnagyobb részecskefizikai kutatóintézetében? 


napokban megadatott számomra, hogy egy busz- 
A nyi ember társaságában ellátogassak a Genf-i szék- 

helyű Európai Részecskefizikai Kutatóintézetbe, 
CERN-be. Utazásunk célja az intézetben működő számító- 
gépközpont meglátogatása volt, ám ehhez azonban elenged- 
hetetlen az ott végzett kutatások alapvető ismerete, ennek 
következtében teljes körű ismeretanyag birtokába jutottam, 
amelyet ezúton szeretnék megosztani a kedves olvasókkal. 


detileg a kutatási eredmények és egyéb dokumentumok au- 
tomatikus megosztását hivatott megvalósítani a különböző 
munkákon dolgozó kutatócsoportok, egyetemek között vi- 
lágszerte. A dolog olyan jól sikerült, hogy mára az internet 
legismertebb és legelterjedtebb szolgáltatásává nőtte ki ma- 
gát. Számos egyéb informatikai kutatás is folyik itt. Ennek 
az az oka, hogy a nagyszabású fizikai kísérletek eddig meg- 
oldhatatlannak hitt problémák elé állítják az ottani informa- 





1. kép CERN legújabb épülete, mellette az irodák, 
géptermek villamos betápja 


A túra leghosszabb, de nem felétlenül a legérdekesebb része 
természetesen az utazás volt. Genf Budapesttől 1400 km-re 
található, nem nehéz kiszámolni, hogy pihenőkkel együtt 
eltart vagy tizennyolc óráig, mire az ember autóbusszal 
odaér. Esetünkben sem volt ez másként, de komolyan mon- 
dom, megérte a hosszú aszalódás. Lássuk, hogy miért! 


CERN 

Az idén 50 éves a kutatóintézet, melynek jelenleg 20 ország 
— köztük Magyarország is tagja. A második világháború 
után, 1954-ben alakult meg a 12 alapító tagország közremű- 
ködésével. Jelenleg a francia-svájci határon terül el, egy kö- 
rülbelül Margit-sziget nagyságú területen. Fő kutatási terü- 
lete a részecskefizika, azaz az atommag felépítése, de más 
területeken is értek el jelentős eredményeket. Ilyen jelentős 
eredmény például a web kitalálása. Az intézetben találták ki 
és implementálták a világ első webkiszolgálóját, amely ere- 
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2. kép Életkép a központi gépterem felső szintjén 


tikai részleget, amelynek feladata, hogy kiszolgálja az inté- 
zetet, hátteret biztosítson a kísérletek számára. 

Minden csoport ingyenesen ellátogathat az intézetbe, s kér- 
het a csoport számára kalauzolást angol francia, német és 
olasz nyelveken. Mi abban a szerencsés helyzetben voltunk, 
hogy kiképeztek néhány ott dolgozó magyar munkatársat, 
hogy alkalmas vezetőnk legyen a túra során, így mi anya- 
nyelvünkön élvezhettük az intézet bemutatását. 


CERN és a fizika 

Mint tudjuk, a részecskefizika az anyag legparányibb építő- 
köveit vizsgálja módszeres alapossággal. Ezt a vizsgálatot 
részecskegyorsítók segítségével végzik. Az alapelv, hogy 

a részecskéket fénysebesség közeli sebességre gyorsítják 
fel,ezáltal hatalmas energia gyűlik össze a részecskékben. 
Ez nem a hagyományos értelemben vett mozgási energia, 
ugyanis a fénysebesség közelében a részecskék tömege az 











Einsteini relativitáselmélet által felismert összefüggés követ- 
kezményeként jelentősen megnő, s mint tudjuk, a tömeg 
energiát hordoz. 

A nagy energiával rendelkező részecskéket ezután ütközte- 
tik más részecskékkel, anyagokkal. A hatalmas ütközés ha- 
tására felszabadul az anyagban rejlő energia, 
és a jelenlévő energiából újra anyagok szü- 
letnek. Az ütközés segítségével tehát az ős- 
robbanáshoz igen közeli időpontot szimulál- 
nak a kísérlet során. 

Az részecskék ütköztetése úgynevezett de- 
tektorokban történik. Ezek vizsgálják a bekö- 
vetkező eseményt, a keletkező anyagokat. 

A kísérlet eredményét ezután tovább elem- 
zik, s következtetéseket próbálnak meg le- 
vonni az elemzés során nyert adatokból. 

A kísérletek elvégzéséhez több gyorsítót is 
használnak párhuzamosan, amelyek legin- 
kább méretükben különböznek egymástól. 
A legnagyobb jelenlegi gyorsító egy 27 km 
kerületű kör alakú szerkezet, s a föld felszíne alatt 100 mé- 
terrel helyezkedik el egy alagútban. Ezen a körpályán ke- 
ringetik, gyorsítják a részecskéket, melyek azután összeüt- 
köznek egymással. A részecskék gyorsítását, pályán tartását 
hatalmas erejű elektromágnesek végzik. Sajnos még az 
ilyen monumentális méretekkel rendelkező berendezések 
sem tudnak választ adni a kutatók minden kérdésére, ezért 
folyamatban van egy új gyorsító építése a régi, 27 km-es 
alagút nyomvonalán melynek neve LHC (Large Hadron 
Collider - Nagy Hadron Ütköztető). Ez a szerkezet még 
erősebb, még gyorsabb, még nagyobb lesz elődjénél. Ottlé- 
tünk során benézhettük abba a csarnokba, ahol a gyorsító 
300 tonnás detektorát építik, szerelik. 


CERN és az informatika 

Gondolom sokakban felmerült az előző bekezdés olvasása 
során, hogy miként is dolgozzák fel és elemzik az ütközé- 
sek során nyert adatokat. A válasz természetesen az, hogy 
számítógéppel, azaz inkább számítógépekkel. Az elején már 
írtam, hogy az informatikai részleg biztosítja a kísérletek 
számítástechnikai hátterét, de arról fogalmam sem volt, 
hogy milyen méretű háttérre is van szükség. Az ütközése- 
ket vizsgáló detektorok jelenleg is többszáz Mbit/sec sávszé- 
lességgel ontják magukból az adatokat, s ez a most épűlő 
gyorsító esetében már a Gbit/sec tartományba esik majd. 
Ennyi adatnak nem csak az szállítása, de a tárolása is igen 
nagy kihívás. A jelenlegi rendszer is többszáz gépből álló 
fürtökből épül fel, melynek eredményeképp körülbelül 

310 terabájt aktív merevlemezes tárolókapacitással rendel- 
kezik az intézet. Ide kerülnek az adatok , átmenetileg", ám 
ez kevés a végleges tároláshoz, ezért az adatokat folyamato- 
san szalagra mentik. Ezek az érdekes szalagos tárolók való- 
jában robotok, melyek lehetővé teszik, hogy ne kézzel kell- 
jen a kazettákat bepakolni a leolvasóba, ha épp szükségünk 
van valamire. 

Ezen túl természetesen szükségük van webkiszolgálókra, 
levelezőkiszolgálókra, terminálkiszolgálókra, útválasztókra, 
hálózati kapcsolókra, és minden lehetséges dologra, ame- 
lyek a meglehetősen nagyra nőtt belső hálózatot üzemelte- 
tik, kiszolgálják. Csak ezeket a feladatokat is processzorok 
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százai végzik. Ezen túl természetesen szükség van , némi" 
számítási kapacitásra a kutatási eredmények kiértékelésének 
céljából. A fenti rendszer természetesen össze van kapcsolva 
a munkatársak által használat többezer munkaállomással, 
amelyek így együtt alkotják CERN informatikai hálózatát. 

A központi gépterem két, egymás alatt elhe- 
lyezkedő hatalmas szoba, amely összesen 
mintegy 2.5MWatt bemenő teljesítményt 
fogyaszt. Ebből sejteni lehet a gépek szá- 
mát, méretét, s nem utolsó sorban a hang- 
ját. Ennyi ventillátor ugyanis már akkora 
hangzavart csinál, hogy egymás szavát 

sem lehet érteni. 

Igen érdekes, hogy a mindennapi feladatok 
ellátására nem IBM, HE vagy Sun nagygé- 
peket használnak, hanem kétprocesszoros 
gépek százainak fürtjét. Ez ugyanis sokkal- 
sokkal olcsóbb, mint az azonos teljesítmé- 
nyű ,szuperszámítógép" . Ennek ellenére 
bizonyos feladatokra, tesztelésre használnak 
klasszikus nagygépeket, de nem ez a jellemző. A munka 
oroszlánrészét PC-k végzik, melyeken nem is olyan megle- 
pő módon Linux fut. 


CERN és a Linux 

Nem csak a kiszolgálók és a fürtök nagy részén fut szabad 
szoftver, de a többezer munkaállomáson is Linuxot futtat- 
nak. Jelenleg a RedHat terjesztés 7.3.1 változatát használják 
— kicsit módosítva. Hozzávettek egy-két CERN-es változta- 
tást (pl. AFS használata), és újabb rendszermagot használ- 
nak a jobb hardvertámogatás érdekében. Ezzel természete- 
sen egy új terjesztés született, amelyet csak CEL-nek, va- 
gyis CERN Linuxnak neveznek. Az az alapvető probléma 

a szabad szoftverrel egy ilyen nagy kutatóintézet esetében, 
hogy nincs hivatalos terméktámogatás, és az , aktív" hasz- 
nálat következtében bizony számos hibára fény derül, ám 
nem biztos, hogy ezek kijavításását meg tudják várni. Ezért 
is használnak kiforrott, stabil változatot, mert a hibákat már 
nagyrészt kijavították. A hosszútávú célkitűzéseik között 
egyébként az szerepel, hogy a Linux használatával próbál- 
ják minél egységesebbé tenni a szoftverkörnyezetet. A kö- 
vetkező CERN-es használatra hivatalosan ajánlott terjesztés 
Red Hat Enterprise Linux 3-on alapul. Vagyis annak egy 
újrafordított változatán — mivel a bináris kereskedelmi 
program, tehát nem érhető el ingyenesen, ugyanakkor 

a forrás nyilvános. 

A belső terméktámogatásra egészen komoly erőforrásokat 
fordítanak, leírásokat, telepítési útmutatókat, javításokat 
tesznek elérhetővé, és külön személyzet van a munkatársak 
segítésére, hogy azok mindenképpen elboldoguljanak 

a gépükön futó Linuxokkal. 

A CERN-nél egyértelműen látszik, hogy a szabad szoftver 
nem csak olcsó, de igen hatékony is. Nincs is erre jobb bi- 
zonyíték, mint az, hogy egy ilyen komoly munkát végző 
kutatóintézet gyakorlatilag a Linux operációs rendszerre 
helyezi informatikai hátterének jelentős részét, s mindezt 
olyan méretekben teszi, hogy közben egy új, önálló ter- 
jesztés születik. 


Komáromi Zoltán 
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Összefoglaló a Linux hangszerkesztőiről 


Akár a munkaasztalunk eseményeihez készítünk menő hanghatásokat, akár 
zenealbumainkat szeretnénk digitalizálni, mindenképpen szükségünk lesz a most 


következő programok valamelyikére. 


zenefájl-szerkesztő program minden hangokkal 
A dolgozó felhasználó nélkülözhetetlen eszköze, hi- 

szen ezzel lehet a rögzített hangokat szerkeszteni, 
kozmetikázni és finomítani. Ezen műveletek némelyike 
a szövegszerkesztésben is megszokottakhoz hasonlóan 
folyik — ilyen például a kivágás/másolás/beillesztés művelet- 
csoport —, mások viszont csak a hangszerkesztés területére 
jellemzőek. 
Ez a cikk egy gyors kirándulásra invitálja az olvasót 
a linuxos hangszerkesztő programok világában. Nincs szük- 
ség arra, hogy bármilyen speciális dolgot tudjunk a digitális 
hangról vagy a digitális hangfeldolgozás elméletéről, és ha 
a bemutatott programok bármelyikét kedvünk szottyanna 
kipróbálni, azt is könnyen megtehetjük. Hiszen nincs másra 
szükségünk, csak egy működő hangrendszerrel rendelkező 
gépre. Mielőtt azonban nekivágnánk felfedező utunknak, 
vizsgáljuk meg, mire is jó egy átlagos hangszerkesztő és ho- 
gyan kell használni. 


A közös tulajdonságok 

A hangszetkesztés egyes műveletei legkönnyebben grafikus 
felületen hajthatók végre. A hangadatok láthatóvá tételével 
könnyen kikereshetők a problémás részek, mint például 

a szünetek vagy az amplitúdó-tüskék. Azzal, hogy a módo- 
sításra váró részeket gyorsan meg tudjuk keresni, nagymér- 
tékben felgyorsul az egész szerkesztési folyamat. A fájl 
egyes területeit pontosan ki tudjuk jelölni, a közelítési/távo- 
lítási lehetőségek pedig bármely ponton lehetővé teszik 

a nagyítást vagy kicsinyítést. Ez azért hasznos, mert így 
könnyen és gyorsan tudunk nagy fájlrészeket szerkeszteni, 
vagy egy-egy nagyon pontosan behatárolt, apró részt érintő 
műveletet végrehajtani. 

Egy jól megtervezett hangszerkesztő programnak min- 
denféleképpen rendelkeznie kell az alábbi műveletek 
lehetőségével: 

e  Kivágás/másolás/beillesztés 

e . Összeillesztés/beszúrás/csere 


1. táblázat A zeneszerkesztők képességei 





Szerkesztőprogram ALSA JACK LADSPA GUI Méretkorlát Licenc 
Snd i i i Motif, GTK [1] lemezhely GAL 
MiXVIews n [2] n n InterViews memória [3] 
DAP n [2] n n XForms memória GBIE 
Audacity i i i wxGTK lemezhely Fal 
ReZound i i i FOX lemezhely (GT [IB 
Sweep i i i GITK lemezhely Ce 
GLAME i n i GIK lemezhely GEIe 
LAoE n [2] n n Java lemezhely GBIs 
Swami i i i (EJITTS lemezhely Gpls 
WavegSurfer i i i Tel/Tk lemezhely [4] 
GNUSsound i n i GTK memória GES 
KWave n [2] n n Ot memória GES 


























[1] Grafika nélkül is lefordítható. [2] Együttműködik az ALSAs OSS/Free emulációval. [3] Nem üzleti felhasználásra ingyenes, 


szabadon terjeszthető. [4] Korlátozás nélkül felhasználható és terjeszthető. 
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1. kép Az alapértelmezett Snd 


e Minták áthelyezése 

e Sávok keverése 

e — Fájlok/sávok szinkronizálása 

e Az időskála tömörítése/kiterjesztése 

e  Csúcsérték-eltolás 

e — Kiegyenlítés/szűrés 

s Mintavételi frekvencia váltása 

e Különböző időformátumok megjelenítése 

e Egy fájl többféle nézetének a megjelenítése 

e Több fájl egyidejű megjelenítése 

e Független X/Y tengely szabályozás 

e Maximális mintavételi érték megkeresése 

e Az amplitúdó-burkológörbék különböző ábrázolás- 
módban (db, peak, RMS) való megjelenítése 

e Csúcspont és amplitúdó burkológörbék szerkesztése 

e Változó sebességű visszajátszás 

e A minták kinyomtatásának lehetősége 

e  Spektrum-analízis 


Amint azt látni fogjuk, az ebben a cikkben bemutatandó 
szerkesztőprogramok teljesítik ezeknek az alapvető elvárá- 
soknak a túlnyomó részét, sőt, gyakran további egyedi lehe- 
tőségeket, eljárásokat is lehetővé tesznek. 

Az 1. táblázat a tulajdonságok egy másik sorát foglalja össze, 
amelyek nagy része — bár nem mindegyik - csak a Linuxra 
jellemző. A táblázatból azt is láthatjuk továbbá, hogy az itt 
bemutatott egyes szerkesztőprogramok milyen módon te- 
szik ezeket elérhetővé. 


A mindennapi használat 

Most pedig gondoljuk végig a hangszerkesztő programok 

néhány felhasználási lehetőségét. Az alábbi lista semmi 

esetre sem teljes, csupán azt mutatja meg, hogy én általá- 

ban hogyan hasznosítok egy ilyen szerkesztőprogramot 

a saját munkámban: 

e Felesleges szünetek eltávolítása a felvételekből. 

e Nagyméretű fájlok feldarabolása kisebb részekre. 

e  Normalizálás. 

e Olyan hanghatások létrehozása, mint a zengés (reverb), 
kórus vagy duplázás (flanging) 

e A lejátszás sebességének csökkentése a hangmagasság 
megváltozása nélkül. 

s — Recsegések és kattogások eltávolítása a felvételekből. 
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2. kép A cikkíró Sdn-je 


e A mintavételezési sűrűség megváltoztatása. 

e A fájlformátum megváltoztatása. 

e A frekvencia-összetétel megváltoztatása, szűrése, azért 
hogy csillogóbb, vagy mélyben gazdagabb legyen. 

e — Zeneszerzés. 


A lista még több tucatnyi művelettel kiegészíthető, minden 
felhasználó talál majd valamilyen különleges alkalmazási 
módot. Oktatói munkámban például nagyon hasznosnak 
bizonyult visszajátszás sebességének megváltoztatása úgy, 
hogy a hangmagasság közben ne változzon. A diákok gyak- 
ran hoznak hozzám olyan felvételeket, amelyek nehezen 
érthetőek, ha eredeti sebességen játsszuk le azokat. Ilyen- 
kor az eredeti cd vagy mp3 fájlt wav formátumba alakítom 
át, beolvasom az Snd szerkesztőprogramba, majd az eredeti 
hangmagasság megtartása mellett egészen addig csökken- 
tem a lejátszási sebességet, amíg minden egyes hangot tisz- 
tán nem lehet érteni. Így sokkal könnyebbé válik a pontos 
átirat elkészítése. Néhány szerkesztőprogram lehetővé te- 
szi, hogy mindezt valós időben végezzük el, sőt, olyan is 
akad, amellyel a beállított ismétlendő szakaszt a lejátszás 
közben tetszőlegesen megváltoztathatjuk, ami rendkívül 
hasznos. 

A normalizálás egy fájl amplitúdóit emeli a viszonylagos 
csúcspontjaira, így az összes amplitúdóérték a csúcspont- 
hoz viszonyítva emelődik meg. A projektfájlok CD-re írás 
előtti normalizálásával az egyes részek közti hangerőkü- 
lönbségeket tudom kiegyenlíteni. A normalizálás a pro- 
fesszionális felvételek előállításának is elterjedten alkalma- 
zott előfeldolgozó művelete. 

A hangszerkesztő programoknak jó hasznát vehetjük 

a rosszul tömörített hangfájloknál is. Néhány szerkesztő- 
program képes az mp3 és Ogg formátum közvetlen beolva- 
sására, más programok viszont először átalakítják ezeket az 
állományokat, és az eredményként kapott fájlt olvassák be. 
Ezekkel az eszközökkel képes vagyok a felesleges szünetek 
eltávolítására és a felvétel megsérült helyeinek kijavítására. 
A hullámforma-nézetben ezek a helyek sérült vagy hiányos 
görbeként jelennek meg. A fájl eredeti formátumba történő 
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3. kép A MiXViews 


visszaalakítása előtt normalizálást és frekvenciakiegyenlítést 
is szoktam végezni. Egy veszteséges tömörítéssel átalakított 
fájl hangfájllá alakítása majd újbóli tömörítése nagyfokú 
minőségromlással jár, ezért a szerkesztőprogram kiegyenlítő 
eszközével újra visszaállítom a frekvenciaegyensúlyt. 

A rendelkezésre álló helyen a bemutatásra kerülő progra- 
moknak csak a legfontosabb vonásait tudom ismertetni, ezért 
minden program esetén csak a kiemelkedő szempontokat 
veszem figyelembe, a mélyebb megismeréshez saját kipróbá- 
lással juthatunk majd el. Kezdjük a körsétánkat néhány, 
Linux alá már régóta elérhető zeneszerkesztő programmal. 

A zeneszerkesztő programok első hulláma akkoriban érte el 
a Linuxot, amikor az OSS/Free volt a rendszer hangfelülete, 

a Motif pedig egy vonzó grafikus eszközkészletnek számí- 
tott. Ezek a programok nemcsak Linux alatti fordításra és fut- 
tatásra készültek, hanem a különböző UNIX rendszerekre is. 


Az Snd 7.0 

Az Snd-t Bill Schottstaedt ügyeskedte össze, a fejlesztést 
már a PDP miniszámítógépek korában elkezdte. Bár a prog- 
ram tudomásom szerint 1996 óta létezik, a Linux támogatá- 
sa csak 1997-ben született meg. Az Snd-t tekinthetjük úgy 
is, mint egy különlegesen hatékony hangfájl-szerkesztő 
programot, egy határtalanul rugalmasan programozható 
hangszerkesztő eszközkészletet, vagy a Common hang- és 
zenekörnyezet grafikus komponensét. A zenei programok 
Common nevű családja tartalmazza Bill Schottstaedt 
Common Lisp Music (szoftveres hangszintetizáló) és 
Common Music Notation, valamint Rick Taube Common 
Music (egy zeneszerzésre alkalmazható metanyelv) prog- 
ramjait. Ezek olyan Lisp-alapú programok, amelyek beállí- 
tásaik révén összetett interaktivitásra képesek. Az Snd haté- 
konysága leginkább a Guile felhasználói felületében rejlik, 
amelynek az alapja a Lisphez hasonló Scheme programozá- 
si nyelv. Az Snd felhasználói felülete tartalmaz egy Listener 
nevű ablakot, amelybe a felhasználó Guile-parancsokat ír- 
hat be, ily módon testre szabva a programot vagy megvál- 
toztatva a megjelenését. 

A képernyőképekből látható, hogy az Snd milyen változa- 
tosan beállítható. Az 1. képen az Snd Motif-változata látható 
az alapértelmezett megjelenéssel. A 2. képen a felhasználói 
felület már egy nagymértékben a saját beállításokra épülő 
képet mutat. Megtörtént az új menük létrehozása a beépí- 
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4.kép A DAP 
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5. kép Az Audacity 


tett DSP-modulokhoz és az LADSPA bővítményekhez, a szí- 
nek és a háttér is egyéni beállítást tükröz, és néhány össze- 
tett eszköz megépítése is megtörtént az Snd hanghatás-fel- 
dolgozójához. A 2. képen látható az Snd által ábrázolt amp- 
litádó-hullámforma, az OpenGL-megjelenítővel együtt, 
amely a hang spektrumát, a frekvenciaösszetevőit ábrázol- 
ja. A különböző kijelzők saját, helyzetérzékeny (Context- 
sensitive) előugró menükkel rendelkeznek, csakúgy, mint 

a fájl kijelölt és nem kijelölt tartományai. 

A hangszerkesztő programok közül az én kedvencem az 
Snd, de biztosan sokan más véleményen lesznek. Ha egy ki- 
csit megismerkedünk a Lisp nyelvvel, az Snd képességeibe is 
nagyobb bepillantást nyerhetünk. Szerencsére az Snd részle- 
tes dokumentációval segít át a tanulási folyamat nehézsége- 
in. Előre elkészített beállítófájlok is rendelkezésünkre állnak 
a testreszabás gyorsabb és egyszerűbb elvégzéséhez. 


A MiXViews 1.30 
Doug Scott MiXViews programjának 1.0 változata 1995-ben 
jelent meg és ezzel az itt ismertetett programok legrégebbi- 
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6. kép Az Audacity Envelope (burkológörbe) eszköze 


ke címet szerezte meg magának. A MiXViews a kezdetektől 
egy egyemberes projekt volt, melynek célja, hogy a UNIX 
és Linux rendszerekhez jó minőségű zeneszerkesztő prog- 
ramot biztosítson. A projekt továbbra is ebben az egyszemé- 
lyes formában folytatódik, és — ennek ellenére, vagy éppen 
ezért — magas színvonalon teljesíti a szerkesztőprogramtól 
elvártakat. 

A MiXViews megbízható programcsomagot kínál az alapve- 
tő zeneszerkesztői teendők ellátására, és ezen felül van né- 
hány olyan szolgáltatása is, amelyet nem találunk meg más 
Linuxra írt szerkesztőprogramban. A phase vocoding 
(beszédtömörítésre kifejlesztett kódoló eljárás — a ford.) és a lineá- 
ris prediktív kódolás (LPC) olyan digitális analizáló-szinteti- 
záló eljárások, amelyek inkább az olyan programok kellékei 
szoktak lenni, mint amilyen a Csound vagy a Common Lisp 
Music. Ezek az eszközök megvizsgálják a hang frekvenciáit 
és amplitúdóértékeit majd egy különleges vizsgálati fájlfor- 
mátumban tárolják azokat. A fájlok egy Csound-hoz hason- 
ló programmal beolvashatóak, s ez a program egy független 
eszközt kínál a fájlban tárolt frekvencia- és amplitúdó- 
összetevők szabályozásához, mielőtt a kapott értékek alap- 
ján a program újra előállítaná a hangfájlt. A MiXViews a sa- 
ját LPC és a phase vocoder eszközeivel teljes körű szolgál- 
tatást nyújt, ráadásul olvasni és szerkeszteni is képes 

a Csound phase vocoder kódolójával előállított fájlokat. 

A 3. képen láthatunk néhányat a MiXViews grafikus eszkö- 
zeiből a phase vocoder és LPC-vizsgálati adatok szerkeszté- 
se közben. Noha a működés hátterében álló elgondolás és 

a matematikai megoldások meglehetősen riasztóak lehet- 
nek, a MiXViews felülete kísérletezésre ösztönzi az embert 
és magukat az eszközöket könnyen kezelhetővé és érdekes- 
sé teszi. 

Ha ki szeretnénk próbálni a MiXViewvs-t, erre az előre lefor- 
dított bináris állományt javaslom. A program lefordítása 
ugyanis egy kicsit trükkös, és egy kevésbé elterjedt grafikus 
eszközkészletre (InterViews) is szükség van hozzá, érdeme- 
sebb a bináris fájlt letölteni, amit azonnal használatba is ve- 
hetünk. 


A DAP 2.1.4 

A DAP (Digital Audio Processor) Richard Kent programozó 
hozzájárulása a több operációs rendszeren futtatható hang- 
szerkesztő programokhoz. A MiXViews-hoz hasonlóan 

a DAP grafikus felülete is egy viszonylag régi grafikus esz- 

közkészletre, az XForms programkönyvtárra épül. A prog- 

ram a MiXViews-ra hasonlít abban is, hogy a szerkeszthető 
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7. kép A ReZound 


tétől függ. Másrészről viszont az AIFF-hangfájlok szerkesz- 
téséhez a DAP rendelkezik néhány kivételesen jól kivitele- 
zett hullámszerkesztő eszközzel. A program szolgáltatásai 
közt megtaláljuk a DSP-modulok egy jól összeválogatott 
gyűjteményét (amely Kai Lassfolk SPKit kódjának a kiter- 
jesztése), és egy jól használható mono-sztereo illetve 
sztereo-kvadro átalakítót. 

A DAP néhány szetkesztőeszköze külön is említést 
érdemel, főleg a Resample és az Edit/Mix menük alatt talál- 
hatóak. A Resample menü az idő megnyújtásával vagy 
anélkül kínál hangmagasság- és mintavételifrekvencia- 
változtatási lehetőségeket, míg az Edit/Mix párbeszédabla- 
kok (Mix és Mix Range) egy csinos grafikus szabályozóesz- 
közt biztosítanak a kevert fájl amplitúdójának kiegyensú- 
lyozásához. Az AIFF fájlformátum és ennek a ciklusok tá- 
mogatására gyakorolt hatása az egész programon érezhető. 
Például ha egy hanghatást alkalmazunk egy fájlon, a DSP 
párbeszédpanele egy eszközt biztosít a ciklusok fenntartá- 
sának és felszabadításának finomítására (4. kép). Bár a DAP 
felépítése kicsit elfogult az AIFF formátum javára, azért ké- 
pes RAW és WAV formátumú fájlok importálására és expor- 
tálására is. Sajnos a DAP fejlesztése nem következetes. 

A XForms-ra épülő grafikus felület felett már eljárt az idő, 
és a fájlméret-korlát is komoly hátrány. A szerző elismeri 

a DAP korlátait, de ha beágyazott hurokpontokkal rendel- 
kező AIFF-fájlokkal kell dolgoznunk, a DAP még mindig 
hasznos eszköznek bizonyulhat. 


A szerkesztőprogramok következő csoportja a Linux hang- 
gal kapcsolatos fejlesztéseinek újabb hullámához tartozik. 
Ezek természetes környezetéhez tartozik a korszerű grafi- 
kus felülettel ellátott eszközkészlet és az olyan Linuxos 
hangrendszer-komponensek, mint az ALSA, a JACK és 

a LADSPA. Fogalmilag is egységesebbek az elődjeiknél és 
sok hasonlóságot mutatnak a Windows és Macintosh fel- 
használók számára megszokott eszközökkel. 


Az Audacity 1.1.3 

Az Audacity az első képviselője ezeknek az újhullámos 
Linuxos hangszerkesztő programoknak. A program C/C-t- -k 
nyelven íródott, a wxWindows felületfüggetlen grafikus 
eszközkészletet alkalmazza, és támogatja a natív LADSPA 
jelfeldolgozó bővítményeket. Az újabb kiadásai emellett 
megfelelnek a JACK követelményeinek is, s ezzel az 
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Audacity felhasználói számára lehetővé válik, hogy a prog- 
ram bemenetét és kimenetét más, JACK-képességekkel ellá- 
tott program felületével kapcsolják össze. 

Az 5. kép az Audacity-t mutatja három, egyidejűleg meg- 
nyitott állománnyal, amelyek egyike egy mono WAV-fájl, 

a másik egy sztereo AIFF-fájl, a harmadik pedig a Sun AU 
formátumában lévő fájl. Az Audacity képes MP3 és Ogg 
fájlok importálására is. Hála az Ogg/Vorbis programkönyv- 
táraknak az Ogg exportálás közvetlenül is működik, az 
MP3 exportálás feltétele azonban egy felhasználó által 
biztosított kódoló program. Az 5. képen működés közben 
láthatjuk az Audacity natív frekvenciakiegyenlítő bővít- 
ményét is. 

Az Audacity grafikus szerkesztőeszközeit élvezet használni. 
A 6. képen a burkológörbe eszközt (envelope tool) láthatjuk 
az 5. képen látott egyik hangfájlra alkalmazva. 

A különálló minták szintjén az Audacity rajzeszközei nagy- 
mértékben megkönnyítik az amplitúdótüskék és egyéb 
folytonossági hibák eltávolítását vagy kijavítását. 

Az Snd-hez hasonlóan az Audacity is rendelkezik egy Lisp- 
alapú programozást lehetővé tévő felülettel, amely Roger 
Dannenberg Nyguist nevű alkotása. A Nyguist egy hang- 
szintetizálásra és jelfeldolgozásra kifejlesztett nyelv, az 
Audacity Effects menüje pedig ehhez kínál egy olyan promp- 
tot, amely lényegében a Snd Listener-jéhez hasonlóan mű- 
ködik. A felhasználó beír egy Nyguist-kifejezést a prompt 
párbeszédablakába, megnyomja az OK gombot és amennyi- 
ben a kifejezés értelmezhető, az Audacity végrehajtja az ak- 
tív hangfájlon a kívánt műveletet. 

Sokkal többet el lehetne mondani az Audacityről, mint 
amennyire itt lehetőségem van. Szerencsére a program ke- 
zelése könnyen elsajátítható, nyugodtan kipróbálhatjuk 
önállóan is a képességeit. 


A ReZound 0.9.0 béta 

A színes felhasználói felület és kitűnő elrendezés teszi 
Davy Zurham ReZound programját kellemes vizuális él- 
ménnyé és könnyen használhatóvá. De a pofás külcsín 
a legkevesebb, emellett ugyanis megtaláljuk a szerkesz- 
téshez szükséges teljes eszközkészletet, kitűnő átviteli 
szerkezeteket, néhány lenyűgöző beépített szűrőt, az 
LADSPA bővítmények támogatását és egy egyedülálló 
remastering/CD-író szerkezetet. 
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A 7. képen látható a ReZound három beolvasott fájllal, ame- 
lyek egyikén éppen a Curved Balance eszköz dolgozik. 

A Curved Balance a ReZound egyik remastering-eszköze, 
amelyek közt találhatunk zajkaput, dinamikasűrítőt, erősítő 
és normalizáló eszközöket. A ReZound egyéb szerkesztői 
ínyencségeivel együtt ezeket az eszközöket használhatjuk 
arra, hogy a tökéletességig gyúrjuk a hangot, mielőtt CD-re 
kiírnánk. A ReZound még ahhoz is biztosít egy egyszerű 
párbeszédablakot, hogy a kész munkát (a cdrdao program 
segítségével) közvetlenül a File menüből írjuk CD-re. 

A ReZound LADSPA-támogatása a Kfetil Matheussen által 
írt LADSPA VST bővítmény (vst.so) alaptámogatásáig ter- 
jed. Ennek a bővítmények támogatására írt bővítménynek 
a használata egy működő, WINE-alapú felületet biztosít 

a VST/VSTi bővítmények Linux alatt történő futtatásához. 
A vst.so bővítmény jelenleg még a fejlesztés egy korai sza- 
kaszában van, ezért a gazdaprogrammal való együttműkö- 
dése nagyon ingadozó lehet. 

A ReZound legfrissebb változata támogatja a JACK zenei ki- 
szolgálót, amellyel a ReZound kapcsolódhat az egymással 
párbeszédre képes hangfeldolgozó alkalmazások JACK- 
hálózatához. További JACK-fejlesztések is várhatók, ilyen 
többek között a hatás-előnézet, a zajeltávolító eszközök, 
natív idő/hang skálázás és még sok egyéb szolgáltatás és 
fejlesztési lehetőség. 


A Sweep 0.6.2 

Első pillantásra Conrad Parker Sweep programja nagyon 
hasonlít a többi itt bemutatott újabb szerkesztőprogramra. Az 
ALSA-képességek biztosítják a megbízható alapvető szerkesz- 
tőfunkciókat, támogatja az LADSPA bővítményeket és tetsze- 
tős és korszerű GTK-felülettel bír. Azonban a Sweep két szo- 
katlan eszközt is kínál, amelyek különleges értékkel ruházzák 
fel a programot. Az egyik a nemlineáris szerkesztés számára 

a többszörös tartomány kijelölésének a lehetősége, a másik pe- 
dig egy érdekes kis eszköz, amelyet Scrubby-nak neveztek el. 
Egy hangfájlban a kijelölés megadása rendszerint úgy törté- 
nik, hogy a kurzort a kijelölendő terület kezdőpontjára 
visszük, megnyomjuk a bal egérgombot, majd azt nyomva 
tartva elhúzzuk a kurzort a szakasz végéig. Ez a kijelölési 
módszer általánosan elterjedt, az eddig bemutatott szer- 
kesztőprogramok mindegyike ezt alkalmazza. Ezt teszi 

a Sweep is, de lehetővé teszi többszörös kijelölések meg- 
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adását is. Tartsuk nyomva a CTRL billentyűt a kijelölés folya- 
mán, és voilL], máris több szakaszunk van kijelölve várva 

a további feldolgozást. 

Az Invert Selection (kijelölés felcserélése) ügyes megoldást 
kínál arra, hogy egy hangfájlban a hatások párbeszédjét 
hozzuk létre. A 8. kép mutatja ennek az átalakításnak a kö- 
vetkezményeit: megadunk egy többszörös kijelölést, alkal- 














mazzuk a reverse hatást ezeken a szakaszokon, felcseréljük 
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a kijelölést (a kijelöltek válnak jelöletlenné és fordítva), 
majd alkalmazzuk az LADSPA hatást az újonnan kijelölt 
részekre. Élvezetes, hatékony és kreatív szolgáltatás. 

A Scrubby a Sweep virtuális lemezjátszótűje, amely képes- 
ségeit tekintve egy szabadon mozgatható lejátszófejnek fe- 
lel meg, és olyan szolgáltatásokat nyújt, amelyeket legin- 
kább egy lemezlovas lemezjátszója esetén szoktak emleget- 
ni. A Scrubby előadóeszközzé változtatja a Sweep-et, ami 
egy hangfájl-szerkesztő programnál meglehetősen furcsa 
tulajdonság. Egy képernyőképpel nem érzékeltethetjük 
eléggé mindezeket a képességeket, ki kell próbálnunk 

a programot és a saját szemünkkel és fülünkkel meggyő- 
ződni az igazságról. 


A Swami 0.9.1a 

A soundfont (SF2) formátum egy olyan összetett hangfájl- 
formátum, amelyben nem kizárólag a hangadatok tárolód- 
nak, hanem a különböző hanghatásokra és az előadásra 
vonatkozó szabályok is. A soundfont formátum megkerül- 
hetetlenné vált a számítógépes hang világában, olyan alkal- 
mazásokban lelve meg otthonát, mint a Csound, jMax, 
Fluidsynth és még sok másik. 

Amennyiben soundfont formátumban lévő anyagokkal sze- 
retnénk dolgozni, kétségtelenül az eszközeink közé kíván- 
kozik Josh Green Swami nevű programja. A Swami egy ki- 
zárólag a soundfont formátumot kezelő szerkesztőprogram, 
amely jól megtervezett grafikus felülettel, és egy sereg 
hasznos szolgáltatással bír. Szerkeszthetünk már létező 
hangfájlokat, vagy létrehozhatjuk a saját soundfont formá- 
tumú fájljainkat a különálló minták szintjétől kezdve az 
összetett hangszerekig. Arra is lehetőségünk van, hogy 
megtervezzük és összeállítsuk saját soundfont-csoportja- 
inkat. Rendelkezésre állnak az eszközök sebességét, átviteli 
görbéjét, billentyűzetkiosztását, és modulátor-útvonalát be- 
állító eszközök is. A Swami pontosan meghatározott célte- 
rülete miatt már nincs igazán mit elmondani róla, első osz- 
tályú, melegen ajánlott Linuxos programról van szó. 


A WaveSurfer 1.5.7 

A WaveSurfer-t Káre Sjölander és Jonas Beskow alkotta meg 
azért, hogy a beszédkutatásban megalkossák a legjobban 
használható eszközt. A WaveSurfer egy tökéletesen használ- 
ható általános célú hangfájl-szerkesztő, de különleges eré- 
nyei akkor mutatkoznak meg igazán, amikor a beszéd vilá- 
gában kell a hangot elemezni, ábrázolni vagy szerkeszteni. 
A WaveSurfer a népszerű 1IcI/Ik parancsnyelven és eszköz- 
készlettel íródott, s így az arra késztetést érző felhasználók 
számára teljes hozzáférést enged a program belső világába. 
A WaveSurfer hangfeldolgozással kapcsolatos műveleteit 

a szintén Káre Sjölander által írt SNACK hangfüggvény- 
könyvtár kezeli. A SNACK maga is kiegészíthető C/C-- -k 
nyelven írt felhasználói bővítményekkel. 

A 10. kép a WaveSurfer egy egyszerű alkalmazását mutatja 
a beszédelemzésben és -ábrázolásban. A főpanel a teljes 
hullámban kiemelt részt jeleníti meg, a felirat-kijelző pedig 
a hangzó fonémát jelzi. A felirat-sáv csak egy a WaveSurfer 
beszédközpontú jellegzetességei közül. A többi közt talá- 
lunk spektografikus megjelenítőket, hangmagasság-görbe 
kivonást, és a támogatott hangfájl- és hangrögzítési for- 
mátumok széles palettáját. 
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13. kép A GNUsound 


A GLAME 1.0.1 

A GLAME fejlesztői a szerkesztőprogramjukban egy szo- 
katlan tervezési filozófiát valósítottak meg. A GLAME 
(GNU/Linux Audio MEchanics) fel van szerelve mindazok- 
kal a hangszerkesztő képességekkel, amiket elvár az ember, 
ezen felül egy hatékony hangszintetizáló és -feldolgozó 
egységet is tartalmaz, melynek neve filternetwork (szűrőhá- 
lózat). A filternetwork egy rajztáblát tartalmaz, amelyen 
ikonok képviselik a hangszintetizáló alapegységeket, ezeket 
összekapcsolva jön létre a hangszintetizáló vagy -feldol- 
gozó lánc. Pillanatnyilag ezek az alapegységek lehetnek 
oszcillátorok, burkológörbe-generátorok, szűrők, [/D- 
modulok és LADSAP-bővítmények. Ha elkészült egy ilyen 
szintetizáló hálózat, akkor futtatható, és valós idejű hang 
vagy pedig kimeneti fájl állítható elő a segítségével további 
feldolgozásra (természetesen a GLAME-ben). A hullámfor- 
ma kijelzőjén jobb egérgombbal kattintva egy felugró menü 
jelenik meg, amelyben megtalálható az Apply Custom me- 
nüpont. Ezt kiválasztva a szűrőhálózatunkat alkalmazhat- 
juk az éppen aktív hangfájlra, ami érdekes feldolgozási le- 
hetőségeket kínál számunkra. 

A 11. képen egy egyszerű példát láthatunk erre. A hullám- 
forma-kijelzőben kijelölt részt egy olyan szűrőhálózattal 
dolgoztuk fel, amely egy erősítővezérlőt, egy LADSPA kés- 
leltető bővítményt és egy flanger-effektet tartalmazott. 

A sáv-modulok és az alapértelmezett I/O-kapuk is a hálózat 
részei, amelyek az eredeti bemenetet és a feldolgozott ki- 
menetet képviselik. 


LAoE 0.6.03 béta 

Oliver Güumann Layer-based Audio Editorja (LAoE, 
réteg-alapú hangszerkesztő) egy újabb egyedülálló tervzé- 
si filozófia hordozója. A szerkesztési munkafolyamat 

a LAoE programban a következőképpen épül fel: létrejön 
egy verem a hangfájlokból, majd ezután következik a kí- 
vánt szerkesztési és feldolgozási eszközök megnyitása 

a veremben lévő egy vagy több réteg (hangfájl) számára. 
Első alkalommal nagyon furcsának tűnt a munkának ez 
az újszerű megközelítése, de miután megértettem 

a program szervezési módját, élvezni kezdtem az elren- 
dezést és egy gyors munkamódszert sikerült kifejleszte- 
nem a segítségével. 

A LAGE külön jutalompontokat kap az eredetiségéért, amely 
a spektrumkijelzőjén való közvetlen szerkesztési lehetőség- 
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14. kép A KWave 


ben nyilvánul meg. Egy, a felhasználó által definiált ecsettel 
lehet az FFT-szűrés feletti területeket lefesteni, maga a szűrő 
pedig finomabb felbontásra is beállítható. Az itt bemutatott 
szerkesztőprogramok nagy része biztosítja a frekvencia- 
összetevők tulajdonságainak megjelenítését, de csak a LAoE 
teszi lehetővé a közvetlen spektrális szerkesztést. 

A LAOE az egyetlen Java-alapú szerkesztőprogram az itt 
bemutatottak közül. A 800 MHz órajelű gépemre -— amely 
nem igazán gyors gép a mai mércével mérve - feltelepítet- 
tem a Sun JDK 1.4 változatát, s a LAoE felhasználói felüle- 
tét minden szempontból gyorsnak és rugalmasan reagá- 
lónak találtam. 


A GNUsound 0.6.1 


Pascal Haakmat GNUSound programja megjelenésében 
szerény, tartalmában azonban annál gazdagabb. Itt is meg- 
találjuk az alapvető szerkesztőeszközök teljes skáláját, 

a LADSPA bővítmények támogatását, és néhány különleges 
eszközt a hangfájlok kijelölésére, kiválasztására és megte- 
kintésére. A GNUSound is alkalmazza a sávos szerkesztési 
lehetőséget, ami azt jelenti, hogy egy folyamat során kijelöl- 
hetünk fájlokat és azokat egy sok sávos magnó sávjaihoz 
hasonlóan használhatjuk a keverésre. 

A GNUSound egy másik ügyes megoldása a hanghatások 
feldolgozásakor használt burkológörbe megvalósítása. A két 
felhasználó által megadott burkológörbe közül az egyik ki- 
jelölhető, mint a hozzá rendelt feldolgozási paraméter ve- 
zérlőgörbéje, ezzel még dinamikusabb körvonalat adva 

a hanghatás feldolgozásunknak. 

Bár a GNUSound eredeti szándék szerint a GNOME alatti 
futtatásra készült, minden gond nélkül sikerült egy Planet 
CCRMA Red Hat 9.0 rendszer alatt lefordítanom és 

a BlackBox ablakkezelővel futtatnom. 


A KiWave 0.7.0-1 


A KWave már 1999 óta fejlesztés alatt áll, így valószínű- 
leg inkább a tiszteletre méltó öregfiúk közé kellett volna 
sorolni. Azonban a fejlesztőcsapat lépést tartott a célkör- 
nyezetével, a KDE-vel, aminek korszerűbb megjelenés 

és néhány érdekes továbbfejlesztés lett az eredménye. 

Az új KWave is megtartotta az eredeti program törekvéseit 
arra vonatkozóan, hogy a fájlok feldolgozása elsősorban 








grafikus eszközökkel folyhasson. A 14. képen láthatjuk 

a KWave aluláteresztő szűrőjének szerkesztőablakát kiegé- 
szítve egy feldolgozó-előnézeti lehetőséggel. A Listen 
gombbal ciklikusan lejátszható a fájl vagy a kijelölt részlet, 
miközben valós időben állítgathatjuk a szűrő paramétere- 
it, ami egy igen jól használható szolgáltatás a hanghatások 
teszteléséhez. A kedvenc eszközeim némelyike, mint pél- 
dául az összegző szintézisgenerátor, nem került az eredeti 
KWave-ből újraírásra. Ezek a szolgáltatások most szürkén 
jelennek meg a menükben és nem elérhetőek, de a fejlesz- 
tők tervezik ezeknek a funkcióknak a visszaállítását, to- 
vábbi tulajdonságokkal kiegészítve. A GNUsound-hoz ha- 
sonlóan a KWave által kezelt fájl méretének is korlátot 
szab az elérhető memória mennyisége, de ezt leszámítva 
egy remek kis szerkesztőprogramról van szó, amely 
nagyszerűen megfelel a KDE környezetben mindennapi 
használatra. 


Záró megjegyzések 

Remélem, cikkemmel sikerült felkeltenem az érdeklődést 

a bemutatott programok némelyike iránt. Hiszitek vagy 
sem, ezeken kívül is rengeteg hangfájl-szerkesztő progra- 
mot lehet találni, itt csak a legnépszerűbbekre összpontosí- 
tottam. A Linux Sound éz MIDI Applications (Linuxos 
hang- és MIDI-programok) honlap Soundfile Editors (hang- 
fájl-szerkesztők) szakaszában teljes listát találhatunk 

a Linux alatt elérhető szerkesztőprogramokról (lásd a háló- 
zaton elérhető Kapcsolódó címek szakaszt). 





Melyik a legmegfelelőbb? Ezt nagyon nehéz eldönteni. 
Személy szerint az Snd iránt érzek nagy rokonszenvet 

a programozhatósága miatt és a ReZound iránt a grafi- 
kus felületének jólszervezettsége okán, de mindenkinek 
saját magának kell kipróbálnia néhányat ahhoz, hogy 
megtalálja az igényeinek leginkább megfelelőt. A legfon- 
tosabb, hogy ne ijedjünk meg ha első ránézésre túl bo- 
nyolultnak tűnik is némelyik program közülük. Közelít- 
sünk úgy hozzájuk, mintha a GIMP-pel tennénk: próbál- 
gassuk véletlenszerűen a szolgáltatásokat, amíg rá nem 
jövünk, mit is csinálnak, és ne féljünk a visszalépés 
gombot használni ha szükséges. Az ilyen típusú progra- 
mok próbálgatása jó szórakozást nyújt, és kreatív csator- 
nákat nyithat meg az emberben. Ha pedig létrehoztok 
valamilyen megosztásra érdemes zenét, ne habozzatok 
a tudomásomra hozni. Gyerünk, dobjatok össze néhány 
élvezetes zajt! 


Linux Journal 2004. június, 122. szám 


Dave Phillips 

Az Ohio állambeli Findlayben élő zenész, 
tanár és író. 1995, a Linuxszal való első pró- 
bálkozása óta aktív tagja a Linux zenei közös- 
! ségének. Ő a szerzője a The Book of Linux 
Music € Sound (A Linux hangjának és zené- 
jének könyve) könyvnek, valamint a Linux Journalban 
megjelent számos cikknek. 
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Linuxos hangfelvevő stúdió 


Linux-alapú merevlemezes rögzítő segítségével saját, olcsó stúdiót hozhatunk lét- 
re. Mostantól közted és a készítendő nagyszerű album közt semmi más nem áll, 
mint a gyakorlás, barátom, csakis a gyakorlás. 


illentyűzet mellett nőttem fel. A hidegháborús grey 
Fő TRS-80-assal kezdtem, aztán jött a zöld-képernyős 

Apple II, IBM klónok, 8088-as, 286-os, PC-DOS, 
majd Windows (amelyben nem volt parancssor) és végül 
a UNIX parancssor. Később a rögzítés kezdett izgatni, ami 
a parancssortól a stúdiók felé vonzott. Továbbra is PC-s srác 
voltam, de soha meg nem fordult volna a fejemben, hogy 
PC-t vigyek a stúdióba. A megfizethető merevlemezek és 
memóriák a túl kicsik, a hangkártyák ócskák, a processzo- 
rok pedig lassúak voltak. 
Aztán megérkezett a Linux. Persze meg kellett várnom míg 
a merevlemezek megnőttek, a lapkák felgyorsultak, de a fi- 
zetős programok továbbra is kívül álltak az elérhetőség kö- 
rén. Fejlesztettem a stúdiómat, miközben sok mindent meg- 
tanultam a Linuxról. Ideje elmesélnem mit alkottam a stúdi- 
ómban és elmondanom hogyan készíthetünk Linux-alapú 
stúdiót. A Linux hangrögzítés általános leírása túl nagy len- 
ne, így ahol szükséges külső forrásokra fogok hivatkozni 
(lásd az hálózati Források szakaszt). 


Hogyan hozzunk létre Linuxos Stúdiót 

Mint általában, a stúdióhoz vásárolandó dolgok és azok be- 

állítása attól függ hogyan döntünk néhány kulcsfontosságú 

kérdésben. Az alkatrészpark olyan egyszerű mint a 3.1415. 

Bármi ami képes Linux-ot futtatni, Linux audio- 

alkalmazásokat is tud működtetni, de azért tartsuk sem 

előtt a következőket: 

e A hangfelvétel cd minőség mellett (44.1KHz, 16 bit) 
5MB-ot használ sávonként, azaz három perc zene szte- 
reóban rögzítve 30MB-ot foglal el a merevlemezen. 

A Többsávú felvétel (Multitracking) kettőnél több sávot 
használ. Egy átlagos, három perc hosszú, 24 sávos pro- 
jekt 360MB-ot használ el, nem számolva a felhasznált, 
rögzített hangot. 

e — Kisebb fejlesztések a RAM méret és a CD-ROM sebesség 
terén mindig jól jönnek ha öregebb felszereléssel dolgo- 
zunk. A CD író szintén jó barátunk, mint az bizonyára 
mindenki tudja. 

e Néhány hibás videokártya zajt visz a hangba. 

e Linux alatt néha nehéz hozzájutni a meghajtókhoz, 
ezért olvasunk utána és kérdezősködjünk vásárlás előtt, 
különösen a hangkártyák esetében. 
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1. ábra Alap Rögzítési Folyam egy egyszerű projekthez 


A program beszerzése majdnem ugyanilyen könnyű. 

A latencia alacsony kell legyen, ezért a rendszermagot ki- 
csit meg kell buherálnunk egy alacsony lappangási folt se- 
gítségével. A merevlemezt megfelelően kell beállítanunk. 
Ezek a témakörök nem férnek el itt, de utánanézhetünk 

a dolognak a Források közt és a weben. Továbbá készítsünk 
Microsoft Windows-os kettős rendszerindítási lehetőséget 
hátha hibakeresésre lesz szükség. Elképzelhető, hogy le 
kell tesztelnünk az alkatrészeket egy másik operációs rend- 
szeren, hogy a problémát leszűkíthessük a Linux meghaj- 
tóra, illetve lehet egyéb feladatunk is, például frissítenünk 
kell a gyári kódot (firmware), amelyet Windows gépen kell 
elvégeznünk. 

Most hogy megvan a gépünk, ideje eldöntenünk milyen 
stúdió alkatrészekre van szükségünk. Én szeretem az adott 
projekt jelfolyamatát figyelni mert abból megtudom mire 
van szükség. Az 1. ábra mutatja be az alapokat, hogy merre 
megy a jel egy rögzítési projektben. Vessünk egy pillantást 
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Szintetizátor 5 
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2. ábra Egyszerű Egy-utas jelfeldolgozás a stúdióban 


a 2. és 3. ábrára is. A második egy egyszerű stúdió drótozási 
szerkezete míg a harmadik az én stúdióm szerkezetét mu- 
tatja be. A lynchpin-el kezdem, ami tulajdonképpen néhány 
gyengítés a jelláncon. 


Analog-Diyital átalakítás 

A digitális rögzítés kulcskérdése az analóg-digitális és a di- 
gitális-analóg átalakítás (ADC és DAC). Más szavakkal, 

a hangnak valahogy be kell jutni a és ki kell jönni e a szá- 
mítógépből. Mindkét irányban választanunk kell több lehet- 
séges megoldás közül. 

Rögzítéshez szükségünk lesz ADC átalakításra. Ez történhet 
a hangkártyában, a digitális keverőn, vagy önálló ADC-n. 

A hang kijövetele (DAC) két részből áll, hallgatásból (vagy 
monitoring-ból amiről alább többet olvashatunk) és a keve- 
résből. Keveréskor jobb ha nem váltunk vissza analóg mód- 
ba. Digitálisan keverhetünk a gépen belül és kívül is, a ke- 
veréket kimentve .wav állományként vagy digitálisan el- 
küldve a digitális rögzítőnek. Azt mindenképpen jegyezzük 
meg, hogy ahhoz, hogy a hangot hallani lehessen, DAC át- 
alakítást kell végezni. Ha mindent digitálisan oldunk meg, 
CD-t készítünk és az autónkban lejátsszuk azt, akkor ott 
történik a DAC. 


A keverő: Analóg, Digitális vagy Program? 

Mint azt nyilván mindenki tudja, a lehetőségek korlátla- 
nok. Tetszőleges összeállításokat választhatunk, például 
analógból digitálissá alakíthatjuk a hangot hangkártyával, 
míg digitálisból analóggá azon kívül, és vica versa. Valami- 
vel egyszerűbb, ha minden átalakítást egy helyen végzünk, 
legyen az a hely akár a hangkártya, akár egy másik eszköz. 
Az, hogy ezzel leegyszerüsítjük-e a dolgot, attól függ, hogy 
van-e külső keverőnk. 

A legegyszerűbb összeállítás esetén, ahol — tegyük fel — tö- 
megcikként kapható hangkártyát használunk egyetlen szte- 
reó kimenettel, a keverést végezhetjük teljes mértékben a szá- 
mítógépen is, és akkor nem sokat kell törődnünk azzal, mi- 
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3. ábra A Szerző stúdiója 


lyen ADC és DAC átalakítás történik a hangkártyában. Ilyen- 
kor nincs külső keverőnk (lásd az alábbi Előerősítő részt). 

Ha viszont rendelkezünk külső keverővel, az mindenkép- 
pen analóg vagy digitális. Mindkét esetben profi hangkár- 
tyára van szükségünk, amely képes szétválasztani a csator- 
nákat, szemben a tömegtermékekkel, amelyek egyetlen 
sztereó keveréket küldenek ki, így kénytelenek vagyunk 

a gépen keverni. 

Ha analóg keverőt használunk, a DAC és ADC részek 

a hangkártyában történnek. Ennek megfelelően olyan hang- 
kártyára vagy hangkártya/breakout box párosra van szüksé- 
günk, amely analóg be és kimenettel rendelkezik. Ilyen pél- 
dául az RME PCI kártyasíne és a Multiface kombinációs kár- 
tya (combination card). Nagyon jó bevezetést találunk erről 
a kártyáról a LJ Weblapján (lásd a hálózati forrásokat). 

Ha digitális keverő mellett döntünk a DAC és ADC magá- 
ban a keverőben lesz. Ennek megfelelőn olyan hangkártyá- 
ra lesz szükségünk, amely a keverőnkkel együttműködő di- 
gitális ki- és bemenettel rendelkezik. Az én esetemben ez 
történetesen az RME HDSP 9652-ese. 

Sok digitális keverő rendelkezik egyébként programcso- 
magokban megtalálható beépített hatásokkal (effektekkel) 
és feldolgozással, például útózengéssel, tömörítéssel és 
zajkapukkal. Az analóg keverők közül csak kevés rendel- 
kezik ilyen képességekkel, így ha hagyományos analóg 
keverést hajtunk végre kicsit többet kell fordítanunk a ki- 
menő hatásokra és feldolgozásra. Ha van rá pénzünk, ér- 
demes beruházni egy ilyenbe, hiszen még ma is sok elő- 
nyük van, de ha olcsón akarjuk megúszni a dolgot, a digi- 
tális keverőt javaslom. 

Néhány kérdés a legjobb hangkártya kiválasztásához: 


e Zajos? 

e Képes felvenni miközben lejátszik (duplex mód)? 
e Hány csatornán képes lejátszani egyszerre? 

e Hány csatornát képes rögzíteni egyszerre? 

e Milyen típusú fizikai [/O csatlakozói vannak? 
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4. ábra Az Ardour Szerkesztőablaka 


e Van beépített MIDI rendszere? 
e Van hozzá Linux meghajtó? 


Ha az utolsó kérdésre keressük a választ, az ALSA Sound 
Card Matrix-ban érdemes körülnéznünk (lásd a forrásokat). 


Mikrofonok 


Ha akusztikus forrásokat rögzítünk, például hangot vagy 
dobokat, mikrofonra is szükségünk lesz. Döntésünket ismét 
a pénzkeret illetve a rögzítendő anyag határozza meg. Pél- 
dául ha közepesen nagy keretünk van és akusztikus gitárt 
és énekest szeretnénk rögzíteni, két darab AKG 414-est ja- 
vaslok (darabja körülbelül 1,000 dollár). Ha ősi hangfelvéte- 
leket kell rögzítenünk és bőven van keretünk, egy darab 
Neumann U87-est javaslok (körülbelül 3,000 dollár). Persze 
az is lehet hogy szűkös a keret, mégis szeretnénk gitárzenét 
és vokált felvenni. Ez esetben két Shure SM58-assal próbál- 
koznék, melynek darabja 100 dollár. Természetesen ha soha 
nem rögzítünk akusztikus forrásokat, kizárólag közvetlenül 
csatlakoztatott szintetizátort használunk, mikrofonra és elő- 
erősítőre sincs szükségünk. 


Előerősítők 

A mikrofonból érkező jelet erősíteni kell, hogy elég erős le- 
gyen a megfelelő rögzítéshez vagy sugárzáshoz. Ha számí- 
tógép-mikrofont csatlakoztatunk egy populáris hangkártya 
mikrofon bemenetéhez, valójában előerősítőt használunk, 
így elegendő erős jelet kell kapnunk. Ha azonban a line in- 
put bemenetre csatlakoztatjuk, aligha fogunk bármit is hal- 
lani. A profi hangkártyáknak nincs is 1/87-as mikrofon be- 
menetük, mivel feltételezik, hogy van külső előerősítőnk. 
A kérdés az, hogy külön erősítőt használjunk, vagy inkább 
a keverőbe építettet. A legtöbb embernek általában tökélete- 
sen megfelel a keverőbe épített erősítő. Az egyetlen problé- 
ma ilyenkor az lehet, ha egy időben többre van szüksé- 
günk, mint amennyit a keverőnk elbír, vagy ha esztétikai 
okokból szeretnénk külső keverőt használni. 

Az előerősítő szükségessége jó indok a külső keverő vásár- 
lására, hiszen ha több analóg bemenettel rendelkező profi 
hangkártya mellet nincs keverőnk, akkor egy rakat külső 
előerősítőre lesz szükségünk, ami általában drágább és ke- 
vésbé rugalmas. 
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3. Képernyőkép — az Ardour keverőablak § 
kimenet kijelölő gombok 





bemenet kijelölő gombok 








5. ábra Az Ardour mix ablakban kiválaszthatjuk a bemenetet, 
a kimenetetés valamennyi csatorna szintjét 


Megfigyelés 

A hallgatáshoz azt használhatunk amit csak szeretnénk, 

a számítógép hangszórótól kezdve a fejhallgatón és az ott- 
honi hangfal/erősítő kombináción keresztül a stúdió refe- 
rencia monitorokig. A hangfalak és a monitorok közt azon- 
ban van egy nagy különbség. A hangfalakat úgy tervezték, 
hogy feljavítsák a felvétel minőségét, a monitorok célja az 
eredeti pontos és a lehetőségekhez képest változatlan 
visszaadása. Amennyiben pontos munkát szeretnénk vé- 
gezni, monitorokra lesz szükségünk. 

A stúdió monitorok többféle változatban kaphatók. A leg- 
fontosabb amit tudnunk kell, hogy a készlet erősített-e. Ha 
nem, akkor erősítőre is szükségünk lesz, az otthoni hangfa- 
lainkhoz hasonlóan. A hagyományos hangfalaink lecserélé- 
se a stúdió monitorokra majd rácsatlakoztatása a meglévő 
erősítőre nem nagy feladat. 


A digitális rögzítő 

A digitális rögzítőnk a Linuxos gép lesz. Az alternatívák ez 
esetben a program kiválasztásánál jelentkeznek. Gyakorlati- 
lag nyílt forráskódú audio-alkalmazások százai állnak ren- 
delkezésünkre Linux alatt, a merevlemezes rögzítőktől 
kezdve a MIDI szekvencerekan át az MP3 rögzítőkig. Vala- 
mennyit lehetetlen lenne most ismertetni, ezért az általam 
használt Ardour nevű stúdió-eszközre fogok koncentrálni. 
(A program beszerzéséről a , Hogyan kezdjünk hozzá" sza- 
kaszban olvashatunk bővebben.) 

A legtöbb programig el is Google-ozhatunk, van jó néhány 
nagyszerű csomag. Jómagam Red-Hat használó lévén 

a Planet CCRMA-t használom. A Planet a Stanford Center 
for Computer Research in Music and Acoustics projekt- 

je melyet egy nagy tudású srác, Fernando vezet. Nando Red 
Hat RPM csomagokat készít a legtöbb audio és videó alkal- 
mazáshoz, meghajtóhoz, eszközhöz sőt, még egyedi rend- 
szermagokhoz is, ráadásul kiterjedt telepítési útmutatót is 
írt a rendszermag, az ALSA meghajtó és program, valamint 
a gépünk teljesítmény növelési lehetőségeiről. 

Egy idézet az Ardour honlapról, , Az Ardour több csatornás 
merevlemez rögzítő (HDR) digitális audió munkaállomás 
(DAW). Egy időben 24 vagy még több, 32-bit szélességű csa- 
tornát képes rögzíteni 48KHz-en...." Az Ardour használatá- 
hoz 2.4-es vagy későbbi, alacsony latenciájú rendszermag, 
0.9-es vagy újabb sorozatú ALSA hangmeghajtó valamint 
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6. ábra A tipikus stúdió alaprajzon megtaláljuk az fő rögzítő 
teremtől elkülönített elhatároló fülkéket (150), de ennél egyszerűbb 
szerkezet is elképzelhető 


a JACK (Jack Audio Connection Kit) szükséges. Ezeken túl 
ablakkezelőre is szükségünk lesz, ugyanis sok más Linuxos 
audió-alkalmazáshoz hasonlóan parancssorból nem fut. 
Magam részéről az Ardourt Fluxbox, néha KDE alól futta- 
tom, de szionte bármelyik kezelő megteszi. 

Az Ardour bármely, ALSA által támogatott hangkártyával 
jól kell működjön. Az egyik ok amiért a HDSP-t választot- 
tam, éppen az, hogy az Ardourt az RME kártyákra gondol- 
va tervezték. Az Ardour nagyon hasonlóan néz ki és műkö- 
dik, mint a Digidesign Pro Tools programja. 

A program indítása mindössze annyiból áll, hogy beindít- 
juk a JACK-et, majd a JACK futása közben futtatjuk az 
Ardour-t. A legjobb ha rendszergazdaként tesszük mindezt, 
ugyanis csak a így érhetünk el valós idejű prioritási szintet. 
A jack általános indítóparancsa a következő: 


jackd -d alsa -d hw:0 


Így a JACK kiszolgáló induláskor az ALSA-t használja esz- 
közként, és az alapértelmezett hangkártya az ALSA eszköze 
lesz. A parancssori kapcsolókról többet megtudhatunk 

a JACK felhasználói Dokumentációjából. A Pro Tools-hoz 
hasonlóan, az Ardour is sokat tud. Annyi hangsávot készít- 
hetünk amennyit a gépünk bír, rögzíthetünk sávokat, ke- 
verhetünk belsőleg, futtathatunk bővítményeket amelyeket 
olyan módon kapcsolunk össze ahogy csak a hangkártyánk 
és mi el tudjuk képzelni. Nálam egy átlagos folyamat körül- 
belül 20 Ardour sávot vezérel 20 különféle kártyakimenetre, 
nyolc további sávot kever az Ardour-on belül, valamint to- 
vábbi két sávot a kimenetre küld, mindezt a digitális keve- 
rőn keverve. Viszonylag egyszerű egy ilyet létrehozni. Egy- 
szerűen ráböktem az Out gombra a mix ablakban minden 
egyes sáv vége felé (5. ábra), majd a listából kiválasztottam 
az output channel-t. Másik lehetőségként keverhetünk min- 
dent az Ardouron belül is, majd a kimenetet .wav fájlként 
küldhetjük ki. A mix ablak grafikus potméterekkel is fel van 
szerelve, pontosan úgy ahogy a Pro Tools-ban. Vannak to- 
vábbá bővítményei és automatái is. Az Automatizálás hasz- 
nálata annyiból áll, hogy rákattintunk az arec-re, beállítjuk 
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a beállítani valókat, lekapcsoljuk az arec rögzítést majd az 
automatizálás visszajátszásához rábökünk az aplay-re. 
Amint láthatjuk, az Ardour használata éppoly magától érte- 
tődő mint bármely profi szintű DAW rendszeré. Ami annyi- 
ra azért nem magától értetődő, de nem is tart túl sokáig 
megtanulni. Mivel a program egyelőre béta állapotban van, 
a dokumentációra még várni kell, de a Pro Tools kézikönyv- 
ének elolvasása átfogó képet ad a működéséről. A hálóza- 
ton nagyon jó Hogyan-okat találhatunk (lásd a forrásokat). 
A cikk születésének időpontjában az Ardour 0.9beta8-1 ál- 
lapotban volt. Nem árt ha ezt észben tartjuk, gyakran men- 
tünk és nem riadunk meg ha hirtelen összeomlik. Hibaje- 
lentéseinkkel segíthetjük az 1-es verziószám elérését (lásd 

a Forrásokat). 


Terem 

A stúdiókban általában vezérlőtermet, rögzítőtermet és 
elszigetelt termeket találunk. Ha van elég helyünk, mindet 
összehozhatjuk, de ha nincs, saját vezérlőtermünkre kell 
szorítkoznunk. A 6. ábrán egy tipikus stúdió alaprajzát 
láthatjuk. 

Vannak akik drága berendezéseket vásárolnak, beteszik egy 
irodába és aztán profi stúdiónak nevezik, ami igen messze 
van az igazságtól. A legtöbb amit a felvételeink minőségéért 
tehetünk, nem az, hogy 5,000 dolláros mikrofont vásáro- 
lunk, nem is az ha 77-húros gitárt használunk amit maga 
Belzebub készített, hanem, hogy stúdiónk akusztikáján javí- 
tunk. Két dolgot kell figyelembe venri, a rögzítési teret és 

a hallgatói környezetet. Könnyű mellényúlni a rögzítési 
hely kiválasztásánál, de még könnyebb teljesen rossz helyre 
pakolni a hallgatói helyet. 


Gyakorlat 

A jó stúdió gyakorlat több egy számítógépnél és a hozzá- 
tartozó csinos nyílt forrású alkalmazásoknál. Például, ne 
feledjünk el a számítógép világán kívüli sávokat is felven- 
ni. Használhatunk csöves előerősítőt, klasszikus utózengőt 
vagy kimenet-feldolgozót. Kísérletezzünk, ne féljünk ke- 
verni a régit az újjal, és nézzük el, ha a programunk nem 
egészen azt adja amit szeretnénk. A dobgép soha nem 
helyettesíti a dobost. Nem árt ha körültekintőek vagyunk 
kábelezés és az általános stúdió karbantartás terén is. 

A hangkábeleink távol legyenek az áramvezetékektől, 
kizárólag derékszögben keresztezzék egymást, és csak 
akkor, ha feltétlenül szükséges, a csatlakozóinkat pedig 
tartsuk tisztán. 


(Megjegyzés: A téma iránt érdeklődő olvasóinknak szíves 
figyelmébe ajánljuk a Kiskapu Kiadó gondozásában 2002-ben 
megjelent LINUX Zene és hang című könyvet — a szerk.) 
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a 1 Aaron Trumm 14 évesen kezdett hip-hop zenét 

, rögzíteni. Azóta hét albumot és számtalan kiegé- 
szítő projektet adott ki. Megalapította és azóta is 
tulajdonosa a NOuit Records-ak, majd létrehozta 
Techno/Classical/ Poetry Project Third Option-t, 
melyben klasszikus zongorajátéka és költemé- 
nyei, valamint Tamara Nicholl költeményei hallhatók. 
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Egyszerű USB illesztőprogram írása 


Az egész szobát beragyogó, színes fényű linuxos gép, és egyszerű 
USB illesztőprogram írása a következő szerzeményed számára. 


Hogy mi köze a kettőnek egymáshoz? 


ikksorozatom eddigi részeiben áttekintettem, 
c hogyan készíthetünk különféle típusú rendszer- 

mag-illesztőprogramokat, és ismertettem a rend- 
szermag-illesztőprogram felületeit — TTY, soros és I2C — 
valamint az illesztőprogrammag működését. Itt az ideje, 
hogy továbblépjünk, és valódi eszközökhöz írjunk valódi 
illesztőprogramokat. Első célunk egy egyszerű, USB-s lám- 
pa Linux alatti beüzemelése lesz. 
Szerkesztőnk, Don Marti egy jópofa apróságot szemelt ki: 
ez a Delcom Engineering által készített USB Visual Signal 
Indicator. Don feladatomul azt tűzte ki, hogy bírjam műkö- 
désre a készüléket Linux alatt. 


Az eszközprotokoll 

Ha egy eszközhöz illesztőprogramot szeretnénk írni, akkor 
először azt kell kitalálni, hogyan tudjuk vezérelni azt. 

A Delcom Engineering egészen nagyvonalú, termékeihez 
teljes USB protokoll leírást mellékelnek, amely a hálózatról 
is ingyenesen letölthető. A leírásban megtaláljuk, hogy az 
USB vezérlőlapka milyen parancsokat fogad, és hogy ho- 
gyan kell azokat használni. 

Egy Microsoft Windows DLL-t is adnak, amelynek alapján 
más operációs rendszerek alá is könnyebben elkészíthető 

a készüléket vezérlő program. 

Az eszközhöz mellékelt leírás ugyanakkor csak a benne 
található USB-vezérlő működését tárgyalja. A különféle 
színűLED-ek kapcsolgatását nem ismerteti, ezt maguk- 
nak kell kitalálnunk. A készülék kinyitása után — vigyáz- 
zunk, nehogy a csavarok eltávolításakor elrepüljön a belül lé- 
vő kis rugó -— vizsgáljuk meg a belsejében található nyomta- 
tott áramkört. 

Ellenállásmérő vagy bármilyen más, zárt áramkör felismeré- 
sére használható műszerrel kideríthetjük, hogy a három LED 
a fő vezérlőlapka 1-es kapujának első három lábára csatlako- 
zik-e. Ha megnézzük a leírást, akkor megtudjuk, hogy az 
1-es kapu lábain megjelenő szintek vezérlésére a Major 10, 
Minor 2, Length 0 parancs szolgál. A parancs az USB pa- 
rancscsomag legkisebb helyiértékű bájtját írja ki az 1-es 
kapura, amelynek alapállapotba hozatalkor az alapértel- 
mezett szintje magas. Megvan tehát, hogy a különféle 
LED-ek beállításához milyen USB parancsot kell külde- 
nünk a készüléknek. 
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Melyik LED melyik? 

Már tudjuk, hogy a kapu lábait melyik paranccsal lehet 
engedélyezni, de azt még nem, hogy melyik színes LED 
melyik lábhoz csatlakozik. Egy egyszerű programmal ezt 

is kideríthetjük, amivel a kapu lábaihoz az összes lehetséges 
értékkombinációt előállítjuk, majd kiküldjük ezeket a ké- 
szüléknek. Egy ilyen program segítségével állt elő az 1. 
táblázat, amely az értékek és a LED-színek párosításait tar- 
talmazza. Tehát, ha a kapu minden lába engedélyezve van 
(0x07 hexadecimális érték), akkor egyik LED sem világít. Ez 
összeillik a leírásban talált állítással, amely szerint alapálla- 
potba hozatal után az 1-es kapu alapértéke magas. Valóban, 
nem sok értelme lenne annak, ha az első bekapcsoláskor 
bármelyik LED is világítana. Most már tudjuk, hogy adott 
LED bekapcsolásához a neki megfelelő lábat alacsony (ki- 
kapcsolt) szintre kell állítanunk. A táblázatból kiderül, hogy 
a kék LED-et a 2-es, a pirosat az 1-es, míg a zöldet a 0-s 

láb vezérli. 


Rendszermag illesztőprogram 

Újonnan szerzett információinkkal felvértezve gyorsan 
dobjunk is össze egy rendszermag illesztőprogramot! 

Az már nyilvánvaló, hogy USB illesztőprogramot készítünk, 
de vajon milyen felületet vegyünk igénybe a felhasználói 
tér felé ? Blokk-eszközként elég furcsa volna egy ilyen lám- 
pát kezelni - itt ugyanis nem adatok fájlrendszerbeli tárolá- 
sáról van szó —, ezért karakteres eszköz mellett döntünk. 
Ha viszont karakteres illesztőprogramot készítünk, akkor 
egy fő- és egy mellékazonosítót kell fenntartanunk neki. 
Sőt, gondoljuk át azt is, vajon hány mellékazonosítót igé- 
nyel az illesztőprogram? Mi történik, ha valaki 100 darab 
USB-s lámpát akar rákötni a gépére? Ha előrelátók aka- 
runk lenni, akkor legalább 100 mellékazonosítót le kell 
foglalnunk, még ha ez súlyos pazarlásnak is tűnik mind- 
azok szemében, akik egyszerre csak egy lámpát akarnak 
használni. Ha karakteres illesztőprogramot írunk, akkor 
arra is ki kell találnunk valamilyen módszert, hogy a kü- 
lönféle színeket külön-külön tudjuk kapcsolgatni. A karak- 
teres illesztőprogramoknál ez hagyományosan különböző 
ioctl parancsokkal történik, de nekünk van egy jobb ötle- 
tünk is, minthogy új ioctl] parancsokkal tűzdeljük meg 

a rendszermagot. 











Kapuérték 
(bináris) 


Kapuérték 
(hexadecimális) 


Bekapcsolt LED-ek 


Minden USB-s eszköz saját könyvtárral rendelkezik a sysfs 
fában, miért ne használjuk tehát a sysfs-t, és miért ne hoz- 
zunk létre három fájlt az USB eszköz könyvtárában, példá- 
ul blue(kék), red(piros) és green(zöld) névvel? Így bármilyen 
felhasználói térben futó programmal át tudjuk kapcsolni 
LED-es eszközünk fényeit, legyen szó C programról vagy 
héjparancsfájlról. Egyúttal megszabadulunk a karakteres 
illesztőprogram megírásának nyűgétől is, és mellékazonosí- 
tókat sem kell szerezni az eszközhöz. 

USB-s illesztőprogramunkkal szemben alapvető elvárás, 

hogy biztosítsa az USB alrendszernek a következő öt dolgot: 

e Egy mutató az illesztőprogram tulajdonos moduljára. 
Így az USB mag helyesen kezelni tudja az 
illesztőprogram modulhivatkozási számlálóját. 

e Az USB illesztőprogram neve. 

e Az illesztőprogram által kezelt USB azonosítók listája. 
Ezt egyrészt az USB mag használja annak meghatározá- 
sára, hogy az adott eszközhöz melyik illesztőprogram 
társul, másrészt a felhasználói térben futó parancsfájlok 
ennek alapján töltik be az illesztőprogramot, amikor 
a felhasználó csatlakoztatja az eszközt a géphez. 

e Egy probeO függvény, amelyet az USB mag hív 
meg, ha az USB azonosítók táblázata alapján egyező 
eszközt talált. 

e Egy disconnect() függvény, amelynek meghívására az 
eszköz rendszerből való eltávolításakor kerül sor. 


Az illesztőprogram mindezeket az adatokat az alábbi kód- 
részlettel teszi hozzáférhetővé: 
static struct usb driver led driver -— ( 


. Owner - THIS MODULE, 
.name -"usbled", 

.probe - led probe, 
.disconnect - led disconnect, 
.id table - id table, 


s 


Az id table változó megadása a következő: 
static struct usb device id id table [] — ( 
( USB DEVICE (GYÁRTÓAZONOSÍTÓ , 
55 TERMÉKAZONOSÍTÓ) ), 
td 
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3; 
MODULE DEVICE TABLE Cusb, id table); 


A led probeO és a led disconnectO függvényekről ké- 
sőbb lesz szó. 
Az illesztőprogram moduljának betöltésekor a fenti 
led driver adatszerkezetet be kell jegyezni az USB mag- 
nál. Ehhez mindössze az usb. register() függvényt kell 
meghívni: 
retval - usb register(gled driver); 
if (retval) 

err("usb register sikertelen. 

"Hibakód: d", retval); 


Amikor pedig az illesztőprogramot eltávolítjuk a rendszer- 
ből, akkor törölni kell bejegyzését az USB magnál: 
usb deregister(gled driver); 
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A led probeO függvény meghívására akkor kerül sor, ami- 
kor az USB mag megtalálja a lámpát. Ilyenkor csak annyit 
kell tennie, hogy elvégzi a készülék kezdeti értékadását és 

a megfelelő helyen létrehozza a három sysfs fájlt. 

Mindezt az alábbi kód végzi el: 

/" A helyi eszköz adatszerkezet kezdeti értékadása "/ 
dev - kmalloc(sizeof(struct usb led), GFP. KERNEL); 
memset (dev, 0x00, sizeof ("dev)); 


dev-sudev - usb get dev(udev); 
usb set intfdata (interface, dev); 


/" A három sysfs fájl létrehozása az USB 
eszköz könyvtárában 7/ 
device create file(ginterface-:dev, 

5 €dev attr blue); 
device create file(ginterface-sdev, 

5 €dev. attr. red); 
device create file(ginterface-:dev, 

5 €dev. attr. green); 


dev. info(ginterface-sdev, 
"AZ USB LED eszköz csatlakoztatása 
s megtörtént.m"); 

return 0; 


A led disconnectO függvény ugyanilyen egyszerű, hi- 
szen csak fel kell szabadítanunk a lefoglalt memóriát és el 
kell távolítanunk a sysfs fájlokat: 

dev - usb get intfdata Cinterface); 

usb set intfdata (interface, NULL); 


device remove file(ginterface-:dev, 

5 gEdev attr blue); 
device remove file(ginterface-:dev, €dev attr red); 
device remove file(ginterface-sdev, 

5 €dev attr green); 


usb put dev(dev-sudev); 
kfree(dev) ; 


dev. info(ginterface-sdev, 
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"AZ USB LED eszköz leválasztása 
5 megtörtént.Mn"); 


A sysfs fájlok olvasásával lekérdezhetjük a LED-ek aktuális 
állapotát, írásukkal pedig be- és kikapcsolhatjuk az egyes 
LED-eket. Ennek érdekében az alábbi makró mindegyik 
LED-hez két függvényt hoz létre, és megad továbbá egy 
sysfs eszközjellemzőfájlt: 
tdefine show set(value) 
static ssizet 
show $ivalue(struct device "dev, char "buf) 
í 

struct usb. interface "intf - 

5 to usb interface(dev); 

struct usb led "led - usb get intfdataCintf); 


return sprintf(buf, "9díWn", 1ed-svalue); 
static ssizet 


set $fvalue(struct device "dev, const char "buf, 
ssize t count) 


í 
struct usb interface "intf - 
5 to usb interface(dev); 
struct usb led "led - usb get intfdataCintf); 
int temp - simple strtoul(buf, NULL, 10); 
1ed-svalue - temp; 
change. color(1ed) ; 
return count; 
3 


static DEVICE ATTR(value, S IWUGO ] S IRUGO, 
s show $ivalue, set $fvalue); 
show set(blue) ; 
show set(red) ; 
show set(green) ; 


Összesen hat függvényünk lesz, show blueO, set blueO, 
show redO, set redO), show greenŐ) és set greenO) név- 
vel, továbbá három jellemző-adatszerkezet, dev attr blue, 
dev. attr red és dev. attr. green. Mivel a sysfs fájlvissza- 
hívók elég egyszerűek, illetve mindhárom érték esetében 
(blue-kék, red-piros és green-zöld) ugyanazt a műveletet 
kell elvégezni, makrót használtunk - így kevesebbet kell gé- 
pelni. Ez a megoldás nem szokatlan a sysfs fájlfüggvények 
körében, például a rendszermag forrásfájának I2C lapka 
illesztőprogramokat tartalmazó ágában, a drivers/i2c/chips 
könyvtárban is láthatunk ilyesmit. Nos, eljutottunk vére 
oda, hogy ha a felhasználó be szeretné kapcsolni a piros 
LED-et, akkor csupán egy 1-est kell írnia a red nevű sysfs 
fájlba. Ennek hatására meghívódik az illesztőprogram 

set redO függvénye, amely viszont a change colorO 
függvényt hoza működésbe. A change colorO) függvény 
így néz ki: 


fdefine BLUE 0x04 
tdefine RED 0x02 
fdefine GREEN  0x01 


buffer - kmalloc(8, GFP. KERNEL) ; 
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A készülék a piros és a kék LED bekapcsolása után 


color -— 0Xx07; 
if (1ed-s5blue) 
color §- -(BLUE); 
if (1ed-sred) 
color §- -(RED); 
if (1Ied-sgreen) 
color §5— -(GREEN) ; 
retval - 
usb. control msg(1led-sudev, 
usb. sndetrIpipe(1ed-sudev, 0), 
0XxI2. 
0xc8, 
(0x02 " 0x100) - 0Ox0a, 
(0xX00 " 0x100) - color, 
buffer, 
8, 
2 " HZ); 
kfree(buffer); 


A függvény első lépésként a color (szín) változó összes bit- 
jét 1-esre állítja. Ezután, ha valamelyik LED-et be kell kap- 
csolni, akkor átállítja a hozzá tartozó bitet. Következő lé- 
pésként USB vezérlőüzenetet küldünk a készüléknek, 
amiben kiírjuk rá a kívánt színbeállító értéket. Elsőre fur- 
csának tűnhet, hogy kisméretű, mindössze nyolc bájtot tá- 
roló buffer változónkat kmal loc hívással hozzuk létre. 
Hogy miért nem adjuk meg egyszerűen a veremben, miért 
vesszük a nyakunkba a dinamikus helyfoglalás és felsza- 
badítás nyűgét? 

Nos, azért, mert a Linux futtatható néhány olyan géptípu- 
son is, ahol a rendszermag-veremben létrehozott adatokat 
nem lehet USB eszköznek elküldeni, vagyis minden, USB- 
eszköznek szánt adatot dinamikusan kell létrehozni. 


LED-ek működés közben 

Megírtuk, lefordítjuk és betöltjük illesztőprogramunkat, és 
már gyönyörködhetünk is abban, ahogyan az kezelésbe ve- 
szi a gépünkhöz csatlakoztatott készüléket. Az 
illesztőprogramhoz kötődő USB eszközök mindegyike az 
illesztőprogram sysfs könyvtárában lelhető fel: 

$ tree /sys/bus/usb/drivers/usbled/ 
/sys/bus/usb/drivers/usbled/ 

"-- 4-1.4:1.0 -- 











../../../ . ./devices/pci0000: 00/0000: 00:0d.0/usb4/ 
5 4-1/4-1.4/4-1.4:1.0 


Az ebben a könyvtárban található fájl egy közvetett hivat- 
kozás az USB eszköz valódi helyére a sysfs fában. Ha bené- 
zünk ebbe a könyvtárba, láthatjuk az illesztőprogram által 
a LED-ekhez létrehozott fájlokat: 
$ tree /sys/bus/usb/drivers/usbled/4-1.4:1.0/ 
/sys/bus/usb/drivers/usbled/4-1.4:1.0/ 
-- baAlternateSetting 
-- binterfaceclass 
-- binterfaceNumber 
-- binterfaceProtocol 
-- binterfacesubclass 
-- bNumEndpoints 
-- blue 
-- detach state 
-- green 
-- ilnterface 
-- power 
"-- state 





"-- red 


Ha most nullát vagy egyet írunk a blue, a green vagy a red 
fájlba, akkor megváltoznak a készülék fényei: 

$ cd /sys/bus/usb/drivers/usbled/4-1.4:1.0/ 

$ cat green red blue 


0 

$ echo 1 5 red 

[gregaduel 4-1.4:1.0]$ echo 1 5 blue 
[gregaduel 4-1.4:1.0]$ cat green red blue 
0 

1 

1 


Ezzel a képen látható állapot áll elő. 


Van másik út is? 

Rendben, írtunk egy egyszerű rendszermag-illesztő- 
programot (amely egyébiránt megtalálható a 2.6-os 
rendszermagfában, a drivers/usb/misc/usbled.c fájlban.) 
ehhez az aprósághoz, de vajon ez a legjobb módja 

a készülékkel való kapcsolattartásnak? Mi van az usbfs 
vagy a libusb használatával? Hiszen ezekkel külön 
illesztőprogram nélkül is vezérelhetjük készülékünket 

a felhasználói térből! Cikksorozatom következő részeiben 
erről lesz szó. Megmutatom, hogyan működik mindez, és 
néhány egyszerű héjparancsfájllal hogyan lehet vezérelni 
az USB-s lámpát. 

Ha valaki látni szeretné, hogyan kell rendszermag 
illesztőprogramot írni valamilyen készülékhez, akkor 

ne habozzon, bátran tudassa velem. 


Linux Journal 2004. április, 120. szám 
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SPF bemutató 


A szemétlevelek (spam) által okozott problémák kezelésében nagy segítséget 
nyújthat, ha időben felfedezzük a hamisításokat. Orizzük meg e-mail címünk 
jó hírét egy egyszerű DNS technika segítségével. 


z SPF (Sender Policy Framework) egy új és egyre 
A népszerűbb hamisítás-ellenes szabvány, melynek 

célja, hogy a különféle férgek, vírusok és szemét- 
levelek ne tudjanak tetszőleges e-mail címet írni az SMTP 
levélboríték ,küldő" mezőjébe. Két fő részből áll: a tarto- 
mánygazdáknak a DNS-ükön elérhetővé kell tenniük az 
SPF bejegyzéseket, az e-mail gazdáknak pedig SPF kézel- 
érésre képes MTA-t kell alkalmazniuk, amelyek felhasznál- 
ják ezeket az adatokat. Az SPF bejegyzések azt a gépet azo- 
nosítják ahonnan a tartomány kimenő levelei érkeznek. 
Bármilyen más helyről érkező levél hamisítottnak számít. 
E kétrészes cikk első részében az SPF alapjaival és kompro- 
misszumaival ismerkedhetünk meg, valamint megtudhatjuk, 
hogy a DNS gazdáknak miképpen kell beállítaniuk az SPF 
bejegyzéseket. A második cikk inkább az e-mail rendszergaz- 
dák számára készül, és azt mutatja be, hogyan kapcsolhatják 
be az MIA SPF védelmet. A cikk 2004 január elején született, 
ennek megfelelően az Internet akkori állapotát tükrözi. 


Férgek, Vírusok, Joe-Job módszerek 


és boríték feladó hamisítás 

Ma saját magamtól kaptam spamet. Én alapítottam 

a 59 httoNwww.pobox.com-ot, és értek az e-levelekhez. 
Gyorsan rá is csaptam a H billentyűre, hogy lássam a fejlécet 
és megvizsgáljam a Received sorokat. Ahogy gyanítottam: 
mint az általam kapott legtöbb spam, ez is egy szélessávú 
hozzáféréssel rendelkező gépről jött. Valószínűleg egy javí- 
tatlan Windows 2000-et futtató, játékra és mp3 hallgatásra 
használt öreg PIII-ról lehet szó, mely koszos alsóneműk 
halma alatt csendesen zümmög valakinek az ágya mellett. 
De az is lehet, hogy egy Idaho-i krumplifarmon zörög, vagy 
esetleg a Central Park-ra van szép kilátása. Akárhogy is, va- 
lószínűleg megfertőzte a spammelőkkel együttműködő 
Sobig vírus valamelyik variánsa. A gép jogos tulajdonosának 
fogalma sincs róla, hogy gépét megfertőzték, nem tudja, 
hogy gépe óránként jó néhány ezer levelet és vírust küldöz- 
get szerte azóta a rég elfelejtett nap óta, amikor az a különös 
csatolmány nem akar megnyílni, hiába böködte. 

A spam üzenetek elrejtik valódi származási helyüket. 

A spammelők megrontott gépeket használnak az üzenetek 
szétküldésére. Hamisítják a levélfejléceket. Átírják 

a Received fejléceket, hogy becsapjanak. Hibás Tárgy-at 
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fabrikálnak, hogy átejtsék a statisztikai szűrőket és meg- 
hamisítják a From sorokat, eljátszva, hogy leveleiket 

a PayPal vagy az eBay küldte. 

A spammelők gyakran a visszatérési utat is meghamisítják. 
Amikor a levél kézbesíthetetlen, visszapattan az eredeti fel- 
adóhoz, akinek a címe a visszatérési útban található. Itt 
nem a levélfejléc From: címéről van szó, hanem az SMTP 
boríték visszatérési címéről, az RFC2821 MAIL FROM me- 
zőről. A spammelő program gyakran használ régi címeket, 
esetleg egyszerűen csak megpróbál kitalálni néhány gyak- 
ran használt nevet, vagy szótártámadást indít. Az ered- 
mény rengeteg hibás és visszapattanó levél. 

A spammerek nem szeretnék ezeket megkapni. Sokkal job- 
ban tetszik nekik, ha valaki más kapja meg őket. Ezért vé- 
letlenszerűen kiválasztanak egy címet, vagy egyszerűen 

a címzettet írják ide. Ez az oka, hogy úgy nézett ki, mintha 
magamtól kaptam volna spamet. Néha valamelyik gyűlölt 
ellenségük címét írják be, készakarva behamisítják a címét 
így aztán elárasztják majd a visszapattanó levelek ezrei. 
1997-ben valaki a levelek visszatérési címébe 

a 5 htteNwww.joes.com címét hamisította, amit aztán annyi 
levél árasztott el, hogy tíz napra leállt — innen a művelet ne- 
ve: joe-job. A Hotmail és az AOL minden nap küzd ezzel 

a problémával: rengeteg spammer hamisít a levélbe AOL cí- 
met, de valójában persze nem az ő kiszolgálóikat használja. 
Hagyományos SMTP eszközök segítségével az AOL semmit 
sem tehet ez ellen. Ha egy pólóra nyomnánk az AOL logót 
és megpróbálnánk eladni azt, egy szemvillanás alatt a nya- 
kunkon volna az AOL összes ügyvédje. A spammelők 
ugyanakkor naponta hamisítják a (daol.com címet. És ezzel 
nekik együtt kell élniük, mert SMTP-t használnak. Az Simple 
Mail Transfer Protocol (SMIP) több mint húsz éve született 
— egy barátságosabb, kedvesebb világban. Az egész Internet 
Maroknyi kutatási intézményből állt. Az SMIP azóta is jól 
szolgál minket, de már mutatkoznak rajta az öregség jelei. 
Az SMTP nyílt és hiszékeny. Szabályai viszonylag kötetle- 
nek. Bármilyen levélküldőt beilleszthetünk, és tetszőleges 
fejlécet komponálhatunk. Felmerül a kérdés, hogy manap- 
ság egy olyan protokoll, ami lehetővé teszi a joe-job féle 
cselekedeteket, vajon nem túl nyitott és hiszékeny-e. 

Ezért kellett kitalálni a feladó-azonosítást: Az SPF kicsit 
komolyabb szabályokat vezet be. 





Szószedet 
DNSBL: IP alapú feketelista 
RHSBL: tartománynév alapú feketelista, elmélet- 
ben magasabb rendű mint a DNSBL, 
manapság azonban kevéssé használt 
a feladó hamisítás miatt (lásd: SPF) 
hamisítás gátló módszer 


Minden SMTP lépésben ... 


Boríték feladó és a fejléc From mezője 
Az SMTP adatátvitel borítékja azok az sorok 
amelyek az DATA utasítás előtt érkeznek. A DATA 
után kapjuk az üzenet fejlécét és a testét. 


Az SMTP--SPF adatátvitel szerkezete 


Amint az SPF vértezetű MTA megkapja a MAIL FROM üzenetet, elvégezheti az anti-spam szűrést. 
Amennyiben a teszt pozitív az MTA a DATA adatainak átvizsgálása nélkül is feltételezheti, hogy a tartalom 
féreg, vírus esetleg spam. Amennyiben az SPF teszt kedvező, további tesztekkel (például RHSBL) növelheti 

a biztonságot. Az SPF hatékonyabb anti-spam eszközökké teszi a RHSBL listákat. 


. . . az SPF vértezetű MTA bizonyos műveleteket végez 





1. ábra Az SPF segítségével a levelező kiszolgáló ellenőrizni tudja, hogy a másik kiszolgáló ténylegesen azt a címet használja, amelyet a levélben állít 


SPF alapú feladó azonosítás 

Amikor levelünket elküldjük valamelyik tartománynak, 
MTA programunk egy DNS keresés (MX lekérdezés) segít- 
ségével találja meg, hogy melyik kiszolgálóra kell továbbíta- 
ni a levelet. Az ilyen kiszolgálót levélcserélőnek hívjuk 
(mail exchanger, röviden MX). Az apró tartományoknak 
többnyire csak egy MX kiszolgálójuk van, a nagy tartomá- 
nyok általában többet tartanak fenn. A tartományra érkező 
levelek annak MX kiszolgálójára érkeznek be. 

Lássuk akkor a nagy ötletet. Az esetek 9999-ában, amikor 

a tartomány elküldi a levelet, a levél a tartomány által irá- 
nyított viszonylag kis számú kiszolgálóról származik. Tekint- 
ve, hogy a tartomány ezeknek a kiszolgálóknak nyújt DNS 
szolgáltatást, bármely, más helyről érkező levelet valószínű- 
leg hamisnak tekinthetünk. Ezt a módszert célzott feladó-sé- 
mának nevezzük (designated sender scheme, 1. ábra). 

A célzott feladó séma fő előnye, hogy segít elhárítani a ha- 
misítókat, ráadásul nagyon egyszerű megvalósítani. Végté- 
re is a tactománygazdák már eleve tudják, milyen kiszolgá- 
lók küldenek leveleket az adott tartományból. Amikor azt 
mondom ,levelet küld a tartományból" , az SMIP külde- 
mény forrását értem alatta, azaz a boríték MAIL-FROM fel- 
adó mezőjében található kiszolgálót. Nem a From: fejlécről 
van itt szó. Ez nagyon fontos különbség. 

A tartományból érkező levelek általában kis számú kiszol- 
gálóról érkeznek. Ez a kis és nagy tartományokra egyaránt 
igaz. Az aol.com levelei az AOL kiszolgálóiról jönnek. A sa- 
ját tartományom levelei természetesen a saját tartományom 
kiszolgálóiról. Mindenesetre biztosan nem jönnek valami 
koszos alsóneműkkel fedett gépről. 
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Sok ISP már ma is alkalmaz hasonló szabályokat, bár eléggé 
esetlegesen és gyakran kicsit hibásan. Az a gond ugyanis, 
hogy az egyik ISP nem igen ismeri a másik ISP belső vilá- 
gát, így gyakran hoz rossz döntést. Például az aol.com leve- 
lező-kiszolgálói elképzelhető, hogy az aol.net tartományba 
is tartozhatnak, vagy fordítva. Nem lenne sokkal egysze- 
rűbb, ha az AOL saját maga adná meg a kiszolgálói nevét 
valamilyen egyszerű, rugalmas, bővíthető nyílt formátum- 
ban, amit bárki felhasználhat? 

Nos, pontosan ezt teszik. Az SPF szabványos, rugalmas, 
bővíthető és nyílt formátum, amit bárki használhat. Az AOL 
pedig épp mostanában kezdte el közzétenni saját SPF be- 
jegyzéseit. Az MTA-k értelmezhetik ezt a bejegyzést, mely- 
nek segítségével már el tudják dönteni, hogy a levél való- 
ban a (Vaol.com tartományból érkezik, avagy hamisítvány. 
Ez az egész szigorítás teljesen önkéntes: azok a tartomá- 
nyok, melyek nem tesznek elérhetővé SPF bejegyzéseket, 
továbbra is ugyanúgy elküldhetik a leveleiket. Néhány szo- 
katlan tartomány esetleg jobban működik, ha nem ad ki 
ilyen bejegyzéseket; rajtuk áll mit szeretnének. A legtöbb 
tartomány valószínűleg szívesen használná az SPF előnyeit. 
A SPF bejegyzések felajánlásához a tartománynak mind- 
össze egyetlen bejegyzést kell a zóna állományhoz adnia. 

A bejegyzés szöveges sor, akár ma is összerakhatjuk. Néz- 
zük meg, hogyan is néz ki ez a bejegyzés. 


SPF példa 

Tegyük fel, hogy a 5 httpAYwww.example.com SPF bejegy- 
zéseket akar felajánlani. Szeretné, ha a világ MTA-i elolvas- 
nák az SPF bejegyzéseit és ennek alapján elutasítanák a ne- 
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Az SPF lekérdezés szerkezete 


Miután az SPF használó MTA megkapta a MAIL FROM parancsot, meghívja 
az SPF könyvtárat és átadja a három szükséges adatot: az ügyfél IP számát, a HELO 
gépnevet, és a boríték küldő címét. Az SPF könyvtár elvégez néhány DNS keresést, 
majd visszaadja az eredményt. Sorra végigvesszük a három lehetséges választ: 
unknown (ismeretlen), pass (elfogadva), fail (elutasítva). 


SPF ügyfél könyvtár 
Paraméterek: (ügyfél IP, HELO gépnév, boríték feladó) 
(192.0.2.2, mx1.example.com, example.com) 


A boríték feladójának 
tartományára irányuló DNS 
TXT lekérdezéssel indítunk. 


Ha a tartomány egy- 
általán nem közöl SPF 
adatokat unknown 
(ismeretlen) értéket 
adunk vissza. 


(amennyiben a feladó 
€a5 a HELO gépnevet 
használjuk fel.) 


De tételezzük fel, hogy 
kapunk SPF adatokat. 
Megvizsgáljuk az adatokat. 


Az Example.com három módszert határoz meg: 

a, mx és a -all. Más módszerek is elképzelhetők, 
de a példa rövidsége érdekében ezeket itt most 
nem említjük. 


Kezdjük az a-val. Ez az ügyfél az example.com? 


Elindítunk egy A leké- 
rést, és megkapjuk az IP számok 


Ha az example.com IP száma (192.0.2.1) egyezik az ügyfél 
IP számával (192.0.2.2) pass (elfogadva) értéket adunk 
vissza. Ez azonban nem igaz. Ezért áttérünk a következő 
módszerre. 


Úgy néz ki, az example.com több MX 
kiszolgálóval 
rendelkezik. 


Megnézzük az mx1.example.com IP számát. 


Amennyiben egyezik az ügyfél IP számával pass Í 


érétotaénánk ász. CTERTETZLBEMHSZONTATÓZÓZ 


Ez történne, ha a levél 
jogos lenne. 


Ha azonban hamisítási próbálkozással állunk szemben, és az 
ügyfél IP száma egyetlen A és MX bejegyzésben sem 
található meg, áttérhetnénk az utolsó, -all nevű módszerre 
és visszaadhatnánk a fail (elutasítva) értéket. 


Amennyiben ideiglenes DNS hiba lépett fel, az error (hiba) 
értéket adjuk vissza. 











2. ábra Az SPF minden bejövő levélre egyszerű DNS-alapú 
keresést alkalmaz 


vében hamisított leveleket. Reméli, hogy az SPF segítségé- 
vel csökkentheti a viaszpattanó joe-job levelek és hibás fi- 
gyelmeztetések számát. Ezért zóna állományához a követ- 
kező sort adja hozzá: 

example.com. IN TXT "v-spfl a mx ptr -all" 

A v-spf1 verzió azonosító mutatja, hogy SPF bejegyzésről 
van szó. A -al1 jelentése: alapértelmezés szerint minden 
levelet utasítsunk el. Azok a tartományok, amelyek egyál- 
talán nem küldenek levelet, az egyszerű v-spf1 -al1 
alaknál meg is állhatnak. Ha azonban a tartomány szeret- 
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ne leveleket is küldeni, meg kell adnia a módszert, 
amellyel eldönthető hogyan kell kinéznie egy hiteles le- 
vélnek. A módszer középre kerül, az -a11 kapcsoló elé. 
Az SPF lekérdezés eredménye az első egyezést mutató 
módszer lesz, mivel a -al1 mindennel megegyezik, 

a végére kell helyeznünk. 

A módszereket balról jobbra értelmezzük. A v-spf1 a mx 
ptr -al1 sorozat alkalmazásakor először megvizsgáljuk, 
hogy a kapcsolódó ügyfél megtalálható-e a tartomány A be- 
jegyzései közt, avagy ha itt nem találjuk meg, az MX kiszol- 
gálók listájában. Ezek után az MTA leellenőrizheti, hogy az 
ügyfél gépneve egyezik-e a tartománnyal. Ha egyik mód- 
szer sem ad eredményt, a -al1 értékelődik ki, és az MTA 
jogosan elutasíthatja a levelet. 

Az A, MX, PTR és IP4 kulcsszavak a tartományok nagy 
többségének bőségesen elegendőek. A spf . pobox . com/ 
wizard .htm1 beállítás-varázslója segít nekünk megalkotni 

a saját taetományunkhoz tartozó SPF bejegyzést. Amennyi- 
ben a mi problémánk összetettebb, kipróbálhatjuk 

a , Advanced SPF" széljegyzet alatt leírtakat. 


Bővíthetőség 

Az SPF számos beépített lehetőséggel rendelkezik. A leg- 
alapvetőbbek segítségével megadhatjuk a tartományunkból 
levelet küldő gépek címeit. Ez a funkció szinte minden tar- 
tomány számára elegendő, hiszen minden tartomány levelei 
gépek viszonylag kis csoportjától érkeznek. De ha a tarto- 
mányunkról érkező leveleket valamilyen más módon külön- 


Továbbfejlesztett SPF 





Exists: az Exists módszer tartománynevekre ráhúzható kifejezéseket használ, ahol makrókat is használhatunk. Például, 
az exists:9firj.9í113. spf.example. com ráhúzható a 2.2.0.192.ceo. spf.example. com névre. Az SPF ügyfél 
A lekérdezést fog végrehajtani a ráhúzott tartománynévre, és ha visszakap valamilyen A bejegyzést (például 127.0.0.2) 
az Exists megadja az engedélyt. Ezt a technikát alkalmazhatjuk például, amikor szeretnénk, hogy a ceo(dexample.com 
különleges felhasználó egy adott gépről, mondjuk a 192.0.2.2-es címről leveleket tudjon küldeni, miután létrehoztuk 

a fenti tartománynévnek megfelelő A bejegyzést. Vannak, akik saját DNS kiszolgálót készítenek az összetett Exists 
lekérdezések kezelésére. Az Exists felhasználásával a határ a csillagos ég. 

Include: ha leveleinket egy másik szervezet kiszolgálóin keresztül küldjük, az Include segítségével adhatjuk meg 

a tartományt, így a megfelelő SPF bejegyzés hívódik és helyettesítődik be. Például, ha a vanity tartomány az ISRcom 
levelező kiszolgálóin keresztül küldi a leveleit, használhatja az include:isp.com bejegyzést. Bármely kiszolgáló, amely 
leveleket küldhet az ISRcom tartomány nevében, ezt követően jogosult lesz a vanity tartományt is használni. Az 
include-dal több tartományt is megadhatunk. 

A Redirect és az Exp: módosítók az eddig látott egyéb megoldásoktól némiképp eltérőek; kettőspont helyett egyenlőség 
jelet használnak. Bár a módszerek megismételhetők, egy SPF bejegyzésben csak egy módszerünk lehet. A Redirect 
módosító hasonlóképpen működik, mint az Include, azzal a különbséggel, hogy az eredeti kérelmet teljes egészében 
helyettesíti az új bejegyzés. Az Exp megadásával leíró szöveget adhatunk meg. Ha az MTA elutasítja a hamisítási 
kísérletet, az itt megadott leíró szöveg jelenik meg az eredeti feladónak visszaküldött SMTP hibaüzenetben. Lehetnek 
jogos felhasználóink, akik nem az általunk megadott SMTP kiszolgálókat használják, az SPF hamar kideríti kik is ők. A leíró 
szöveget egy URL-re is állíthatjuk, ahol a levelező ügyfél helyes beállításaival kapcsolatos további információkat helyezünk 
el. Az itt bemutatott módszerek részletes leírását az 5 http:Mwww.spf.pobox.com/mechanisms.htm!l címen találjuk. 


SPF és hagyományos Antispam módszerek 





A DNS feketelisták vagy gátlólisták (blocklist, DNSBL): Az IPv4 tér 32 bit széles; 2? körülbelül 4.2 milliárd — 4.2 milliárd 
homokszem megtöltene egy dömpert. Képzeljük el, hogy valamennyi homokszemet feketére vagy fehérre festjük. 

Az IP-alapú feketelista derék próbálkozás, de túlságosan alacsony szinten próbálja kezelni a problémát. A jó DNSBL 
rendszernek el kell döntenie, hogy az adott IP cím spammelő vagy sem, csakhogy helyesen kell döntenie mind 

a 4.2 milliárd IP cím esetében. Ne csodálkozzunk rajta, hogy a DNSBL listák jönnek-mennek. A fenntartóik idővel 
belefáradnak és feladják. 

Jobboldali feketelisták: az RHSBL tartományneveket használ, a DNSBL IP címeket. A tartománynevek sokkal 
alkalmasabbak az internetes objektumok azonosítására, azonban a RHSBL listák még nem olyan népszerűek, mint 

a DNSBL táblák. Vajon miért? A spam soha nem jön a spammer.net-ről. Sokkal valószínűbb, hogy a yvahoo.com 
címet hamisítják. Ez az ahol az SPF segíthet: ha a spammelők valódi nevükről küldik a leveleket, feltartóztatásuk 

is egyértelművé válik. 

Címellenőrzés: a MAIL fázisban leellenőrizhetjük a boríték feladóját, ha megpróbálunk levelet küldeni neki. Ha a próba- 
üzenet címzett ismeretlen üzenettel tér vissza, nem fogadjuk el az üzenetet. Ez azért hasznos, mert a spammelők gyak- 
ran választanak véletlenszerű címeket. Azonban ahogy a címellenőrzés egyre általánosabbá válik, a spammelők is vár- 
hatóan létező címeket fognak hamisítani-még egy érv az SPF mellett. 

Aláírás alapú megoldások: a PGP/GPG és S/MIME felhasználók aláírják üzeneteiket. A fogadó a kulcs kiszolgálóról 
letöltött kulcsokkal ellenőrizheti az üzenet hitelességét. Olyan szerekezeteket is javasoltak, ahol maga a DNS 
működne a nyilvános kulcsok tárházaként. Ezek a megoldások azért hasznosak, mert a .forward állományok 
módosítás nélkül működhetnek tovább. Ugyanakkor hátrányuk, hogy a hitelesség ellenőrzéséhez a levélnek 

keresztül kell haladnia a csővezetéken, így sávszélességet és CPU időt használ el. Mindenesetre a fenti módszerek 
bármelyikét alkalmazó tartomány használhatja az SPF módszert annak megadására, hogy minden aláírás nélküli 
üzenetet el kell utasítani. 

Válasz: Nyilván nem szeretnénk válaszolni egy spamre, különösen nem egy hamisított spamre. Ha az SPF megmutatja 
nekünk, hogy a küldő címe egyértelműen hamis volt, nyugodtan törölhetjük a levelet anélkül, hogy válaszolnánk rá. 


böztetjük meg, mondjuk mindig S/MIME jellel látjuk el őket, . majd ezekkel is együtt tud működni. A jövendőbeli mecha- 
a megszokott a vagy mx helyére az smime kódot kell írnunk.  — nizmusokat értelmező SPF bővítmények már helyesen fog- 


A küldő azonosítás egyik megközelítési módja a dedikált ják tudni értelmezni őket. Azok az SPF bővítmények ame- 

feladó mechanizmus (designated sender mechanisms) ki- lyek nem értették meg az új mechanizmust, ismeretlennek 
alakítása (A, MX, PTR és IP4). Újfajta küldő-azonosítási fogják tekinteni, és úgy veszik, mintha a tartományunknak 
módszerek is kialakulóban vannak. Az SPF bővíthető, így egyáltalán nem lenne SPF bejegyzése. 
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Az Altartományok és az MX kiszolgálók védelme 
Manapság a spammelők tartományneveket hamisítanak. 
Lehet, hogy hamarosan gépneveket hamisítanak. Lehet 
hogy megpróbálják joe-job módszerrel célba venni a lapto- 
punkat, kipróbálva az username(gibook.example.com cí- 
met. Ezért nem árt ha az altartományunkat is megvédjük. 
Kezdjük az MX kiszolgálókkal, majd térjünk át az összes 

A bejegyzéssel rendelkező gépre. Lássuk miért. 

A visszapattanó levelek küldő mezőjében a MAIL FROM: cs 
üzenetet találjuk. A nullfeladó-cím biztosítja, hogy vissza- 
pattanó levelek ne pattanjanak vissza újra, és ne hozzanak 
létre ciklust. Amikor az SPF üres feladó címet lát, visszatér 
a HELO parancsban megadott címhez. Amikor a saját MTA- 
nk küld visszapattanó levelet, a gépnevet megadja az elkül- 
dött HELO parancsban. Ha ez a gépnév megtalálható az SPF 
rendszer listájában, az üzenet átmehet. Az SPF tehát egyút- 
tal a HELO hamisítást is meggátolja. 


Utazó Postás (Mailman) és továbbítási problémák 

Az SPF célja: legtöbb hasznot hozni a lehető legolcsób- 
ban. Megszigorítja a szabályokat, így a huligánok nehe- 
zebben tudnak rossz dolgokat művelni, mindeközben 
nem zavarja a jó embereket, akik jó dolgokat tesznek. 
Néhány komolyabb felhasználó, aki ki szeretné használni 
a SMTP laza szabályait, elképzelhető, hogy kényelmet- 
lennek találja az SPF rendszerét. Ebben a szakaszban 
bemutatjuk, milyen problémákat okozhat az SPF a ko- 
moly felhasználóknak, valamint megnézzük hogyan 
kerülhetjük ki őket. 

A legtöbb felhasználó a leveleit az ISP SMTP kiszolgálóin 
keresztül küldi ki. A legtöbb modern ügyfél támogatja 

a SASL azonosítási módszert vagy, ahol a felhasználóknak 
kívülről kell betárcsázniuk az ISP hálózatára, a POP-before- 
SMIP eljárást. Azok a felhasználók akik miden levelüket az 
ISP SMTP kiszolgálóin keresztül küldik, automatikusan 
SPF-kompatibilisek, azaz semmit sem kell tenniük. 
Csakhogy néhány komoly felhasználó, aki a laptopján saját 
MTA-t futtat véletlenszerű IP címekről is küldhetik a levele- 
ket, és így teljes mértékben kikerülik az ISP kiszolgálóit. 

Az SPF ezen felhasználók igényeihez is alkalmazkodik: 

a továbbfejlesztett mechanizmus (lásd a ,Iovábbfejlesztett 
SPF" széljegyzetet) lehetőséget ad bizonyos felhasználók- 
nak, hogy ne kelljen az ISP SMTP kiszolgálóit használniuk. 
Továbbra is azt tehetnek, amit akarnak. 

Vannak komoly felhasználók, akik tucatnyi vagy még több 
címet használnak, amelyeket aztán /etc/aliases bejegyzé- 
sekkel vagy .forward állományokkal irányítanak egy helyre. 
A klasszikus átirányítás elvei szerint a boríték küldője válto- 
zatlan marad és csak a címzett címe íródik át. Ez azonban 
problémát jelenthet, amikor az üzenet megérkezik a rendel- 
tetési helyére — ugyanis továbbra is az eredeti feladó címet 
tartalmazza, így az SPF teszt hamisnak minősíti. 

A megoldás szerencsére nem nehéz, egyszerűen csak át kell 
váltanunk újrapostázásra, ahol a küldő címe is átíródik. Ezt 
rengeteg módon megtehetjük. A nekünk legmegfelelőbb 
megoldást az SPF FAO (spf.pobox.com/fag.html:forwarding) 
leírásából választhatjuk ki. A legtöbb végfelhasználónak nem 
sokszor akad dolga a továbbítással, inkább csak a komo- 
lyabb felhasználóknak van szükségük ilyen megoldásokra. 
Amennyiben harmadik fél által nyújtott szolgáltatást haszná- 
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lunk az alumni, vanity tartományon vagy egyéb üzleti továb- 
bító szolgáltató (pobox.com) gépén keresztül, elvárhatjuk, 
hogy meg tudják oldani nekünk az újrapostázást. 


Spam feltartóztatása: Ez is a megoldás része 

Az SPF elsődleges célja a hamisítás megakadályozásának to- 
vábbi előnyei is vannak. Nem szeretnék több spamet kapni 
saját magamtól, és nyilvánvalóan nem szeretném, ha te kap- 
nál olyan spamet, ami azt állítja, hogy én küldtem. A férgek 
és vírusok általában szintén hamisítják a küldő címét, így eze- 
ket is megállíthatjuk az SPF segítségével. A hamisítás megaka- 
dályozása egy további előnnyel is bír. Ha a spammelők kény- 
telenek a saját nevüket használni, meg tudjuk állapítani mely 
tartományok jogosultak és melyek spammelők. Vannak, akik 
már most is ezt teszik: A jobboldali blokkolási listák (RHSBL) 
a DNS blokkolási listák (DNSBL) névkiszolgáló alapú változa- 
tai. Azok a spammelők, akik nem félnek saját tartományukat 
használni hamar az RHSBL listákon találják magukat, így 
könnyedén megállíthatjuk őket. Az SPF alapú világban az 
RHSBL sokkal fontosabbá és hatékonyabbá válna. 


Miért használjuk az SPF-et? 

A nagy tartományok, például az ISP-k, bankok, jól is- 
mert cégek szeretik saját maguk irányítani a cégjelüket. 
Szinte kötelességük megvédeniük a nevüket. Az 

5 httoNwwwaaltavista.com éppúgy terjeszt SPF bejegyzé- 
seket, mint az AOL és az Oxford. Minden nap új és új tarto- 
mányok lépnek be az egyre bővülő körbe. A kisebb tarto- 
mányok egyszerűen azért használnak SPF rendszert, mert 
nem szeretnének joe-job áldozatokká válni. 

A fogadói oldalon az ISP-k MTA fejlesztésekbe kezdenek, 
és persze szívesen használják az SPF-et hiszen így keve- 
sebb a hamisítás, ezzel együtt kevesebb spam, vírus és fé- 
reg. A sávszélesség költségük is lecsökken, hiszen az SPF 
segítségével még az adat elküldése előtt lecsaphatnak 

a spammelőre. Nincs szükség semmilyen titkosításra, 
ellenőrzésre vagy aláírásokra. Az SPF pénzt takarít meg. 


Adaptálás 

Mire ez a cikk megjelenik, az SPF támogatás már valószínű- 
leg beépített része, vagy letölthető modulként elérhető lesz 
a legfrissebb SpamAssassin, Postfix, Sendmail, Exim és 
gmail terjesztésekben. Az üzleti antispam-terjesztők az SPF 
támogatása mellett döntöttek; egyikük, a Declude Junk- 
Mail, jelentette, hogy az SPF éles környezetben is sikeresen 
megállítja a kéretlen leveleket. 

Ha minden jól megy, az SPF szabvány a közeljövőben RFC 
szabvánnyá válik. Több ezer tartomány, köztük néhány 
igazán nagy, azonban már most is terjeszti az SPF listákat. 
Nincs okunk várni; már ma érdemes kiadni saját SPF 
bejegyzéseinket. 
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u — ] Meng Weng Wong a pobox.com e-mail továbbító 
cég alapítója és CTO-ja, amely tizedik évfordulóját 
ünnepli ez évben. Jelenleg science-fiction novella- 
sorozatán dolgozik, amely olyan bolygón játszódik, 
ahol Clarke híres elképzelése nyomán, nanotech- 
nológiával valósították meg a fantasy mágiát. 


6. 








SPF IMTA-k és SRS 


Az előző cikkben áttekintettük, hogy DNS segítségével hogyan jelölhetjük meg 
eredetiként kimenő elektronikus leveleinket. Most eljött az ideje annak, hogy 

a bejövő levelek ellenőrzéséről is gondoskodjunk, és megvédjük felhasználóinkat 
a hamisított, kéretlen levelektől és a férgektől. 


Sender Policy Framework (SPH küldő házirend-ke- 
A retrendszer) a válaszútvonal hamisítása ellen segít 

védekezni — amit általában férgek, vírusok és le- 
vélszemét terjesztők alkalmaznak. Az SPF életre hívása két 
szakaszból áll. Először a rendszergazdák SPF-bejegyzéseket 
tesznek közzé a DNS-ben. Ezek a bejegyzések az egyes tar- 
tományok által a kimenő levelek kezelésére használt kiszol- 
gálókat adják meg. Az SPFre képes MTA-k (mail transport 
agent, levéltovábbító ügynök) később ellenőrzik a bejegyzé- 
seket. Ha egy levél nem az SPF-ben megadott kiszolgálóról 
érkezik, akkor bátran hamisnak nyilváníthatjuk. 
A továbbiakban - kapcsolódva előző írásomhoz - felvázolom, 
hogyan ruházhatjuk fel SPF képességekkel a levélkiszolgálón- 
kat. Szó lesz arról is, hogy az elektronikus leveleket továbbító, 
vagy weben előállító szolgáltatások a küldő módosításával 
hogyan működtethetők tovább az SPF bevezetése után is. 


Az MTA bővítése SPF-képességekkel 

A linuxos világ legfontosabb levéltovábbító ügynökei (MTA) 
a Sendmail, a Postfix, a Omail és az Exim. Noha a legtöbb 
levélszemétszűrő megoldást kínáló cég már megoldotta az 
SPF támogatását (vagy legalábbis tervezi), az MTA-k eseté- 
ben ez a feladat ránk vár. Az SPF-MTA együttműködést két- 
féle módon valósíthatjuk meg. 

Aki szereti maga lefordítani a programokat, az az SPF letölté- 
si oldalán kezdjen, itt ugyanis mindenki megtalálja a saját 
MTA-jához készült SPF modult és a hozzá tartozó telepítési 
útmutatót. Aki inkább csomagkezelővel telepíti a programo- 
kat, az nagy valószínűséggel talál olyan előre fordított MTA- 
változatot, amely eleve támogatja az SPF használatát. A leg- 
több beépülő modulnak szüksége van a Mail::SPF::Ouery 
Perl könyvtárra. 

A könyvtár a CPAN-ról telepíthető a legkönnyebben, de 
csomag formájában is megpróbálhatjuk előkeresni. Lénye- 
gében egy egyszerű programot biztosít az SPF-lekérdezések 
parancssorból való futtatására. Egy egyszerű démont is tar- 
talmaz, amely UNIX-tartományon vagy inet foglalaton ke- 
resztül kezeli az SPF-kéréseket. 

A beépülő modulok nagy része alapesetben az SPF alapú 
ellenőrzésen megbukó üzenetek elutasítására szólítja fel az 
MTA-t, a többihez pedig egy Received-SPF fejlécet fűz. 
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Ha kissé mértéktartóbbak akarunk lenni, akkor elutasítás he- 
lyett a Received-SPF: fail sorral is bővíthetjük a fejlécet. Ezt 
a lehetőséget a beépülő modulok leírása ismerteti bővebben. 


sendmail 

A Sendmail beépülő modulok fogadására szolgáló felületét 
Milternek nevezzük. (Lásd az internetes forrásokat.) Az 
újabb Sendmail-változatok alapesetben is támogatják a 
Milter használatát. A Sendmail foglalat alapú felületen ke- 
resztül tartja a kapcsolatot a Milterrel. Értesíti azt a befelé 
irányuló SMTP-tranzakciókról, a Milter pedig megmondja 
a Sendmailnek, hogy mit kell tennie. A Milter démonként 
fut, indítása is külön történik. Az SPF weboldalon két Milter 
érhető el, egy Perl és egy C alapú. A Perl alapú változat kifi- 
nomultabb, ha viszont gyorsabb működést szeretnénk, ak- 
kor a C alapú változatot válasszuk. A Milter és a Sendmail 
együttműködéséhez néhány sorral bővíteni kell a 
sendmail.mc fájlt, újra kell fordítani a sendmail.cf-et, majd 
újra kell indítani a Sendmailt. Ha inkább nem akarjuk hasz- 
nálni a Miltert, a libspf-hez tartozik egy olyan folt is, ami le- 
hetővé teszi az SPF közvetlen beépítését a Sendmailbe. 


Postfix 

A Postfix 2.1 házirend démon felülettel rendelkezik. Ennek 
működése nagyon hasonló a Milteréhez: a Postfix csatlako- 
zik a démonhoz, átadja a szükséges adatokat, majd a dé- 
mon egy művelettel válaszol a Postfixnek. Ha a 2.0-s sorozat 
újabb, fejlesztői kiadását futtatjuk, akkor ellenőrizzük, hogy 
2.0.18-20040122-es vagy újabb változattal rendelkezünk-e. 

A házirend démonok beállításai a main.cf és a master.cf 
fájlban szerepelnek. Kezelésükről a Postfix gondoskodik, 
indításukat és leállításukat szükség szerint elvégzi, így 
ezzel nem kell foglalkoznunk. A Postfix házirend démon 
Perlben készült, működéséhez szükség van a normál 
Mail::SPF::Ouery könyvtárra. 


Exim 

Az Exim 4 újdonsága az Access Control Lists (ACLs), ami 

egy sokoldalú, kisméretű programozási mininyelv levélsze- 
mét szűrésére és egyéb házirend jellegű döntések leírásához. 
Az SPF Exim alatti használatához szükséges ACL kód nagyjá- 
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ból 12 sort tesz ki. Telepíteni kell a Mail::SPE::Ouery könyvtá- 
rat és futtatni ennek SPF démonját, amely megadott foglala- 
ton hallgatózik. Az SPF ACL csatlakozik az spfd-hez és átadja 
neki az ügyfél IP-címét, a HELO kapcsolót és a MAIL FROM 
küldő címet. Ezután kap valamilyen SPF-eredményt, választ 
az SMTP-kiszolgálóra vonatkozóan, valamint egy Received- 
SPF fejlécsort. Az spfd-t külön kell indítani. 


Omail 

A Omail nem rendelkezik olyan beépülő modul felülettel, 
mint a többi MTA. Létezik viszont olyan SPF-folt, amely az 
SPF-et közvetlenül a Omailbe építi. Emellett sok Omail- 
használó gpsmtpd segítségével szűri leveleit. Aki ezt a meg- 
oldást választotta, az beépülő modulként könnyen be tudja 
kapcsolni az SPF-et. 

A C SPF könyvtár készítésében James Couzens játssza a fő- 
szerepet. A libspf-hez Omailhez és egyéb MTA-khoz ké- 
szült folt egyaránt tartozik. 


A beépülő módul kipróbálása 

A beépülő modul telepítése és bekapcsolása után két ellen- 
őrzést kell végrehajtani. Az első és legfontosabb annak el- 
lenőrzése, hogy a tiszta levelek átjutnak-e. Ha nem, akkor 
lehetséges, hogy nem fut valamelyik szükséges program, 
ekkor végezzünk ismételt ellenőrzést. Ha továbbra is gond- 
jaink vannak, állítsuk vissza a régi rendszert, és jelezzük 

a hibát az spf-help levelezési listán. 

A második próba alkalmával a hamisított levelek elutasítá- 
sát kell ellenőrizni. Ha kézzel lépünk be az SMTP- 
kiszolgálóra, akkor MAIL FROM:linuxjournal- 
test(Valtavista.com származással hozzunk létre egy levelet. 
Az altavista.com tartományt levelezésre nem használják, 
ezért ilyen küldőre minden esetben FAIL jelzést kell kap- 
nunk. Többen kérdezték, hogy a próbaüzenetekben szere- 
peljen-e a test/teszt szó. Ezt kockázatos megtenni, mert ha 
megbízható ügyfelet vélnek felismerni, saját MTA-nk és 
SPF-ünk hamis levelet is átengedhet. Telneten keresztül te- 
hát ne lépjünk be a helyi gépre, inkább használjuk gépünk 
valódi állomásnevét, és ha mód van rá, a kapcsolatot külső 
állomásról kezdeményezzük. Ha 550-es választ és az 

5 httpNspf.pobox.com/why.htmIl oldalra hivatkozó hiba- 
üzenetet kapunk, a rendszer működik. Ha másodlagos MX- 
et használunk, akkor utasítsuk SPF-ügyfelünket, hogy ne 
tagadja meg ennek leveleit. Minderről részletesen a beépü- 
lő modul telepítési útmutatójából tájékozódhatunk. 


Received-SPF: a kódok jelentése 

Mint azt látni fogjuk, leveleink immár egy Received-SPF 
fejlécet is tartalmaznak, amelyben különféle eredménykó- 
dokat találhatunk: 


e NONE: A tartományhoz nem tettek közzé SPF-bejegyzé- 
seket. Az MTA-nak a szokásos módon kell folytatnia 
munkáját. 

e PASS: A levél nem hamis, de az sem biztos, hogy valódi. 
Ne feledjük, a levélszemetek küldői is közzétehetnek 
SPF-bejegyzéseket. A tartományt valamilyen fehérlista 
alapján ellenőrizni kell. Ha a küldő egy általunk meg- 
bízhatónak vélt fehérlistán szerepel, akkor a további el- 
lenőrzéseket nyugodtan elhagyhatjuk. 
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e  FAIL: A levél hamis, nyugodtan eldobhatjuk. Csekély va- 
lószínűséggel előfordulhat, hogy a levél tiszta feladótól 
érkezett, ám annak beállításait hibásan adták meg. Ha ez 
a helyzet, akkor a küldő fél hibaüzenetet kap, amelyben 
levélküldő ügynökének (Mail User Agent, MUA) SMTP 
AUTH használatára való beállítására szólítjuk fel. Az SPF 
tervezési elve szerint jobb egy szívélyes hibaüzenet kül- 
dése mellett hibát elkövetni, mint mély hallgatással egy 
levélszemetes ládába hajítani az üzeneteket. 

e SOFTFAIL: Lehetséges, hogy az üzenet hamis, de a tarto- 
mány internetszolgáltatója már megkezdte a felhaszná- 
lók rendszereinek átállítását SMTP AUTH használatára, 
tehát előfordulhat, hogy a levél tiszta. Az üzenetet célsze- 
rű fogadni, de érdemes további ellenőrzéseknek alávetni. 

8 — NEUTRAL: A tartományban megkezdték az SPF bevezeté- 
sét, alapértelmezett válaszuk ?a11. Szeretnék azt a lát- 
szatot kelteni, mintha a válasz NONE lenne, amíg a 
SOFTFALL és a FAIL alapértelmezett válaszokat be nem 
vezetik. A nagyméretű, több millió ügyfelet kiszolgáló 
internetszolgáltatók lassan követik a dolgokat - ez van, 
nem az ő hibájuk. 

e — ERROR: Alkalmi hiba lépett fel a DNS-keresésnél. Normál 
esetben ilyenkor saját MTA-nknak 450-es kódú ideigle- 
nes hibát kell jeleznie. 

e — UNKNOWN: Állandó jellegű hiba miatt az SPF-keresés fél- 
bemaradt. Lehetséges, hogy gépelési hiba van a bejegy- 
zésben, esetleg egy másik tartományra mutat, amelyhez 
viszont nem tartozik SPF-bejegyzés. 


Az $PF bevezetésének ára 

Az elmúlt tíz évben az elektronikus levelezés egyre na- 
gyobb szerephez jutott. Hogy pontosan mennyire függünk 
tőle, arról csak akkor kapunk képet, amikor egy-egy féreg 
elárasztja a hálózatot. Az elemzők ilyenkor rutinszerűen 
közlik, hány milliárd dolláros kárt okoznak a gazdaságnak 
a kéretlen levelek és a vírusok. Az SPF sikere is bizonyítja, 
az emberek nagyon várják már a változásokat. 

Minden változásnak megvan azonban az ára. Ha volna 
valami fájdalommentes megoldás a levélszemét gondjára, 
már nyilván mindenki bevezette volna. A levélszemét elleni 
küzdelem régóta húzódik, mert a legnagyobb szakértők 
képtelenek megegyezni a szükséges ellenlépésekben -— sze- 
rencsére a vita lezárulni látszik. Minden levélszemét elleni 
megoldásban közös és alapvető elem a küldő fél hitelesíté- 
se. Erre már számos modellt dolgoztak ki, ám ezek közül 
az SPF ,megnevezett küldő" szemléletű megoldását a leg- 
könnyebb megvalósítani. A jövő kétségkívül a titkosításé, 
de arra még várni kell. Az elsősegélyként alkalmazható SPF 
előnyei azonnal megmutatkoznak, és megvalósításával sem 
kell késlekednünk. De mi az SPF használatának ára? Min- 
den megnevezett küldő alapú sémánál két dolog módosulá- 
sával kell számolni. Az első az, hogy az SPF ellehetetleníti 
a szó szerinti levéltovábbítást. (1. ábra) Vannak olyan szol- 
gáltatások, amelyeket az emberek általában azért vesznek 
igénybe, mert változatlan e-mail címet biztosítanak. Ezek 

a UNIX . forward és a /etc/aliases fájloknál megismert mó- 
don továbbítják a leveleket. Amikor egy levél elhagyja a ki- 
szolgálót, a borítékján szereplő válaszútvonal változatlan 
marad. Az SPF használatakor azonban a továbbított levelek 
hamisnak tűnnek. A megoldás az, hogy a továbbító szolgál- 











A szó szerinti továbbítási és a küldő újraírási séma 


annegeredeti.com 
MAIL FROM: c anngeredeti com— 


bobopobox.com 
MAIL FROM: — annégeredeti.com— 


coboharmadik.com 


A hagyományos, szó szerinti levéltovábbításnál 
a válaszútvonal változatlan formában marad 
benne a kimenő levélben. Az SPF világában a 
továbbító szolgáltatóknak át kell írniuk a válasz- 
útvonalat, ha meg akarják őrizni működőké- 
pességüket. A Mail::SRS Perl-könyvtár és ennek 
libsrs nevű, C alapú változata megfelelő 
segítséget ad ennek elvégzéséhez. A teljes 
időben futó továbbító szolgáltatók általában 
közvetlenül MTA-jukba építik ezeket a szol- 
gáltatásokat. A kisebb gépeken erre nincs 
szükség, elég az srs segédprogramot meghívni. 


bob(opobox.com .forward fájlja: 
" [/usr/bin/srs cobcoharmadik.com" 





A pobox.com /etc/aliases fájlj 
srs0: " [/usr/bin/srs -reverse" 
srs1: " [/usr/bin/srs -reverse" 


2 


További tájékoztatásért lásd: 
http://spf.pobox.com/srs.html 


A pobox.com mint továbbító szolgáltató 
átírja a borítékon szereplő feladót, így 

a levél átmegy a harmadik.com által 
végzett SPF-ellenőrzésen. 


anngeredeti.com 
] MAIL FROM: — anngeredeti.com— 


bobopobox.com 
l MAIL FROM:c SRSO--yf09g-Cworig.com. —ann(Dpobox.comz 


coboharmadik.com 


Az újraírt válaszútvonal tartalmazza az eredeti feladót is, így a fehérlisták használhatók marad- 
nak — igaz, némi buherálás árán. Megelőzendő a rosszfiúkat abban, hogy a továbbító szolgálta- 
tókat nyílt levéltovábbításra használják, az SRS egy kivonatmezőt (yf09), valamint egy időbé- 
lyeget is (Cw) hozzáad a levélhez, utóbbi a címek lejárását okozza. Ha a cob(oharmadik.com 
címre nem lehet továbbítani a levelet, az visszajut a pobox.com-hoz, amely az eredeti.com-nak 
adja tovább. Érdemes megjegyezni, hogy egyik adatot sem kell elrejteni. 


cob(oharmadik.com 
] MAIL FROM: — SRS1--pobox.com-—yf09—-Cwsorig.com—annoharmadik.com— 

dobonegyedik.com 
MAIL FROM: € SRS1--pobox.com-yf09g-Cworig.com —annonegyedik.com— 

shevekDotodik.com 


Mi történik, ha más továbbítók is vannak a láncolatban? Semmi baj, az SRS0 jelző tudatja 
velük, hogy SRS alapú továbbítás történt. A második továbbító az SRSO-t SRS1-re 
változtatja, feljegyzi az első továbbító címét, a többi adatot pedig változatlanul hagyja. 

A többi továbbító már csak az utolsó tartománynevet változtatja meg, vagyis az adatsor 
nem nő a végtelenségig. A Mail::SRS egy adatbázis-kezelésre képes változattal is 
rendelkezik, amely rövid címeket biztosít. 


leveleket eldobják. Az 
újabb, haladó szellemi- 
ségű webhelyek, mint 
például az Orkut, vala- 
mi ilyet tesznek. Ha vi- 
szont a levelek fonto- 
sak, és elküldésükre a 
webhelyre szabályosan 
bejelentkezett felhasz- 
nálók nevében kerül 
sor, valamint a webhely 
üzemeltetője korábban 
ellenőrizte a felhaszná- 
lók e-mail címét, akkor 
a webhely SRS-t is al- 
kalmazhat - vagyis, ha 
beágyazzák a felhasz- 
náló válaszcímét, akkor 
a visszapattanó levele- 
ket is könnyedén el 
tudják juttatni rá. Jogos 
a kérdés: mi lesz az átál- 
lás ideje alatt? Nem 
lesznek leállások, amíg 
a továbbító szolgáltatók 
nagy nehezen megvaló- 








sítják az SRS támogatá- 





1. ábra SPF használatakor az elektronikus levelek hagyományos továbbítása nem lehetséges 


tatók újraírják a levelek válaszútvonalát. Ugyancsak így kell 
tenniük a leveleket a .forward és a /etc/aliases fájlok alapján 
továbbküldő szervezeteknek. Ez a megoldást SRS-nek 
(sender rewriting scheme, küldő újraírási séma) nevezzük. 
Az eredeti küldő címét egy újraírt, SPF-megfelelő válasz- 
címbe ágyazza be. Ha egy üzenet visszapattan, akkor hoz- 
zánk érkezik be, ilyenkor ki kell hámoznunk a címet, majd 
továbbítani a levelet az eredeti feladónak. A továbbító szol- 
gáltatóknak akkor is meg kell tenniük mindezt, ha nem 
használnak SPF-et, az internetszolgáltatók ugyanis már vé- 
geznek SPF jellegű ellenőrzéseket. Az SPF csupán egy szab- 
ványos eljárást biztosít arra, amit a legtöbb helyen már 
most is megtesznek. Ahogy a felelősséggel vezetett szolgál- 
tatók néhány éve megszüntették a nyílt levélküldési lehető- 
ségeket, úgy a következő hónapok során az SPF-megfelelő 
továbbítást is be fogják vezetni. A 5 htteXwww.pobox.com 
már alkalmazza az SRS-t, és hamarosan más továbbító szol- 
gáltatók is követni fogják a példáját. A jó hír az, hogy az 
SPF-et fejlesztő közösség az MTA-khoz tartozó SRS kódot is 
elkészítette. Ezek a foltok ugyanonnan érhetők el, mint az 
SPF foltok. Az SRS elterjedése csupán idő kérdése. Az SPF 
azonban a webről küldött leveleket is megállíthatja. Az üd- 
vözlőlapok küldésére használható oldalak és az ,elküldöm 
ezt a cikket egy barátomnak" jellegű szolgáltatások általában 
nemcsak a From: fejlécben de, borítékon is a szolgáltatást 
igénybe vevő személy címét tüntetik fel. Az SPF az ilyen le- 
veleket nem képes megkülönböztetni a hamisítottaktól. 

A gondra kétféle megoldás létezik. Az első, hogy úgy dön- 
tenek, az ilyen levelek nem túl fontosak, válaszútvonalként 
a senkirvpélda.com-ot adják meg, aztán a visszapattanó 
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sát? Mi lesz azokkal a 
szolgáltatókkal, akik túl 
lassan lépnek, vagy 
képtelenek alkalmazkodni? Van itt egy apró titok. Nagyjából 
sejteni lehet, kik lógnak ki a sorból. Van egy fehérlistát, ame- 
lyen a jó szándékú hamisítók szerepelnek. A listán szerepel 
például a pobox.com, az acm.org, az eBay és számos ,elkül- 
döm ezt a cikket e-mailben" jellegű szolgáltatást kínáló hír- 
magazin. Az eddig említett SPF-ügyfelek mindegyike képes 
kezelni a fehérlistát. A fehérlista formájában tehát minden 
ismert SPF-ügyfélnél megvan az utolsó esély a végleges el- 
utasítás előtt. Ha az anyukánk küld nekünk egy levelet az 
SPF-ügyfelünk fogadni fogja a levelet, noha műszakilag ha- 
mis lesz. (Ha a levelet út közben olyan rendszer — például 
egy barátunk linuxos kiszolgálója — is továbbítja, amely nem 
szerepel a fehérlistán, akkor hozzá kell adnunk saját MTA-nk 
fehérlistájához ezt a gépet.) Amikor az acm.org megvalósítja 
az SRS támogatását, a kérdés megoldódik. Az SPF-et bírálók 
ellenérvként a levéltovábbítás ellehetetlenülését szokták fel- 
hozni. Az SPF közösség nem hagyta szó nélkül a kifogásokat, 
mindent megtett az átállás megkönnyítésének érdekében. 
Két megoldást is kidolgoztak, egy rövid és egy hosszú távút. 
Jó ha tudjuk, minden változás fájdalmas. Az SPF-re való átté- 
rés is gondokkal jár, ám a betegségtől gyakran csak a kelle- 
metlen injekció segítségével szabadulhatunk meg. Márpedig 
az elektronikus levelezés nagyon beteg. Vannak, akik szerint 
a levélszemét meg fogja ölni, de én ezt nem hiszem. Szerin- 
tem az SPF biztos kézzel fogja a gyógyulás útjára segíteni. 
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A Yum használata az RPM-frissítésekhez 


A legtöbb ismert biztonsági kockázat elkerülhető, ha eltávolítjuk a nem használt 
programokat és naprakészen tartjuk a rendszerünket. Ehhez egy új eszközt 
mutatok be, amelyet már három népszerű Linux rendszercsomag használ. 


rendszerünk sokszor a programhibák miatt válik 
A sebezhetővé. Hogy az ebből eredő kockázatot 

csökkentsük, kiemelkedően fontos, hogy frissítsük 
a Linux rendszert minden alkalommal, ha egy új biztonsági 
javítócsomag válik elérhetővé. A kérdés súlyát jól mutatja, 
hogy annak idején hosszabb írást is szenteltem a témának, 
mind a Linux Journal oldalain (, Staying Current without 
Going Insane", 2002 júliusi szám), mind a könyvem (Buil- 
ding Secure Servers With Linux, Biztonságos kiszolgálók 
építése a Linux segítségével) 3. fejezetében. 
A Debian és SuSE rendszerek frissítése az írások megjelené- 
se óta eltelt két év alatt sem változott jelentősen, még min- 
dig az apt-get és a YaST a feladat végrehajtására leginkább 
használt eszköz. A Red Hat világa azonban egy új és figye- 
lemre méltó eszközzel lett gazdagabb, amit Yum néven em- 
legetnek (a Yellow Dog Updater, Modíified kifejezés után). 
Ebben a hónapban azt fogom elmondani, hogy miképpen 
szerezhetjük be ezt a kis programot, hogyan helyezhetjük 
üzembe, és mi módon használhatjuk fel a Red Hat, Fedora 
vagy Mandrake rendszerünk naprakészen tartásában. 


A Yum legfontosabb vonásai 

Ahogy a program neve is utal rá, a Yellow Dog Updater, 
Modified Yellow Dog Updater, vagyis Yup program leszár- 
mazottja, amely a Macintosh gépekre írt Yellow Dog Linux 
Rendszercsomag része. Noha a Yup kizárólag csak a Yellow 
Dog (Macintosh) rendszereken fut, a Yum működik Red 
Hat, Fedora, Mandrake és Yellow Dog Linuxon, amelyek- 
ben a Yup-ot váltotta fel. A Yum a Duke Egyetemen műkö- 
dő Linux(ODUKE csapat projektje, mely csapat két legbefo- 
lyásosabb tagja Seth Vidal és Michael Stenner. 

Pár szóban összefoglalva, a Yum az RPM-et használó rend- 
szerekben azt a funkciót tölti be, amit az apt-get a Debian- 
ban, vagyis egy egyszerű parancsot biztosít, amelyet prog- 
ramcsomagok automatikus telepítésére vagy frissítésére 
használhatunk, miután önműködően megtörtént az összes 
olyan egyéb csomag telepítése és frissítése is, amelyek szük- 
ségesek a kívánt program függőségeinek kielégítésére. 

A Yum valójában két parancsból áll: a yum az ügyfél-oldali 
parancs, míg a yum-arch a kiszolgáló oldali utasítás, 
amellyel a Web- vagy FTP-kiszolgálóink Yum-tárrá való ala- 
kításához szükséges fejrész-állományokat hozhatjuk létre. 
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A yum-arch parancs ismertetése meghaladja ennek a cikk- 
nek a kereteit, de mindenképpen szükségünk lesz rá, ha 
nyilvános Yum-tárat szeretnénk létrehozni, saját Yum-tár 
kialakítását tervezzük a helyi rendszereink karbantartásá- 
hoz, vagy pedig egy nem hálózati Yum-tárat hozunk létre 
a merevlemezünkön. A yum-arch parancs használata egy- 
szerű, és a yum-arch(8) man-oldal minden szükséges infor- 
mációval elátja a felhasználókat. 

Az apt-rpm paranccsal szemben - amely az apt-get egy 
népszetű átültetése az RPM-alapú rendszercsomagok keze- 
lésére — a Yum kifejezetten az RPM-formátumú csoma- 
gokhoz lett létrehozva. Mindehhez Michael Stenner még 
azt is hozzáteszi, hogy ,a Yum tervezése során elsődleges 
szempont az egyszerűség és megbízhatóság volt, s egyúttal 
nagyobb a hangsúly a biztonságon és megbízhatóságon, 
mint az ügyfél oldali testreszabás esetében." 


A Yum beszerzése 

A Yum letöltését kínáló Weboldal (amelynek címét 

a Kapcsolódó címek részben találhatjuk meg) elmagya- 
rázza, hogy az egyes Red Hat vagy Fedora változatok 
esetén a Yum melyik változatát érdemes letöltenünk. 

Ha a Fedorát használjuk, A Yumot a Fedora Core 1 tartal- 
mazza, a yum-2.0.4-2.noarch.rpm csomag pedig megtalál- 
ható a Fedora 1-es számú telepítőcédéjén. Amennyiben 

az általunk használt rendszer a Mandrake 9.2, a yum-2.0.1- 
1mdk.noarch.rpm csomagot a telepítőcsomag contrib/i586 
könyvtára tartalmazza. 

A Yum teljes egészében Python nyelven íródott, ezért 
ahhoz, hogy a Yum RPM-csomagjait telepíteni tudjuk, szük- 
ségünk van a Fedora/Red Hat python, gettext, rpm-python 
és libxmI2-python csomagjainak (vagy ezek Madrake-meg- 
felelőinek) feltelepítésére. Jó eséllyel ezek a csomagok már 
korábban a rendszerünkre kerültek. 


Hol találhatunk Yum-tárhelyeket? 

Honnan tudja a Yum az RPM-csomagokat letölteni? Az erre 
alkalmas hely rendszerint a Világháló valamelyik távoli 
szöglete. Mivel a biztonsági kérdéseket igen fontosnak 
tartom, innentől kezdve a Yum-ot a biztonsági foltok letöl- 
tésének szemszögéből fogom vizsgálni. A cikk hátralévő ré- 
szének fókuszában a hálózaton keresztül történő frissítések 











1. lista A Fedora Core 1 /etc/yum.conf állománya 


[main] 
cachedir-/var/cache/yum 
debuglevel-2 
logfile-/var/1og/yum. 1og 
pkgpolicy-newest 
distroverpkg-fedora-release 
tolerant-1 

exactarch-1 


[base] 

name-Fedora Core $releasever - $basearch - Base 
baseur1-http://fedora. redhat . com/releases/fedora 
-core-$releasever 


[updates-released] 

name-Fedora Core $releasever - $basearch - 
Released Updates 

baseur1-http://fedora. redhat . com/updates/release 
d/fedora-core-$releasever 


ftlIupdates-testing] 

$name-Fedora Core $releasever - $basearch - 
Unreleased Updates 

$baseur1-http://fedora. redhat . com/updates/testin 
g/fedora-core-$releasever 


2. lista A testre szabott [base] szakasz 


[base] 

name-Fedora Core $releasever - $basearch - Base 
baseur1-http: //mirror . eas . muohio . edu/fedora/ 

5 Tinux/core/$releasever/$basearch/os/baseur1- 
s http://fedora. redhat . com/releases/ 

5 fedora-core-$releasever 

gpgcheck-1 

failovermethod-priority 


állnak, de a teljesség érdekében meg kell jegyeznem, hogy 
a Yum képes az RPM-csomagok helyi, vagy olyan, látszó- 
lag helyi fájlrendszerekből való olvasására is, mint amilyen 
az NFS. 

Akár távoli, akár helyi kiszolgálóról van szó, az RPM- 
csomagoknak egy Yum-tárat kell alkotniuk. Ennek tartal- 
maznia kell egy headers nevű könyvtárat, amely magában 
foglalja a Yum számára az RPM-csomagok függőség-ellen- 
őrzéséhez és megfeleltetéséhez szükséges információkat. 
Ez az oka annak, hogy nem választhatunk ki tetszésünk 
szerint egy régebbi Red Hat tükrözést vagy Mandrake 
CD-ROM-ot. Amennyiben a Fedora Core 1 vagy 1.90 vál- 
tozatot használjuk, lehetőségünk van a Yum-ot bármelyik 
Fedora tükrözésre ráirányítani. Mivel a Yum a Fedora hiva- 
talosan is támogatott frissítő eljárása, a tükrözések már ele- 
ve Yum-tárhelyként is szolgálnak. 
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Hallottunk már a Fedora Legacy Project-ről? A Fedora erő- 
feszítéseinek ez a vonulata a korábbi Red Hat rendszercso- 
magokhoz kínál biztonsági frissítéseket, jelenleg a Red Hat 
7.3, 8.0 és 9.0 változatokhoz. Ebből következik, hogy sok 
Fedora-tükrözés Red Hat frissítéseket is tartalmaz Yum- 
tárhely formátumban. 

Ha kétségeink lennének, a különböző rendszercsomagok 
számára készült Yum-tárhelyek egy kicsi, de jól használható 
listáját találjuk a Kapcsolódó címek szakaszban. A listában 
szereplő hivatkozások mindegyike egy szövegblokkot is tar- 
talmaz, amelyet közvetlenül az /etc/yum.conf fájlunkba is át- 
másolhatunk - erről hamarosan részletesen is szó lesz. Ha 
más megoldást nem találunk, írjuk be a Google-be a rend- 
szercsomagunk nevét és a Yum repository (Yum-tár) kifeje- 
zést, így szintén rábukkanhatunk a megfelelő helyekre. 


A Yum beállításai 

A Yum beállítása meglehetősen egyszerű, mindössze egyet- 
len fájl szerkesztéséről van szó, amelynek a neve -— ahogy 
az megjósolható — /etc/yum.c. Az 1. lista azt az alapértelme- 
zett /etc/yum.conf fájlt mutatja be, amely a Fedora Core 1 
Yum RPM csomagban juthat el a felhasználóhoz. 

Amint látható, ez a fájl globális változók beállításának listá- 
jából áll, amelyet egy vagy több [server] blokk követ ([base] 
és [updates-releasedl] az 1. listán). Ezek mindegyike külön- 
böző típusú RPM-csoportok beállításait határozza meg. 
Nem szándékozom az összes lehetséges globális illetve 
kiszolgáló-blokk beállítást ismertetni, erre használhatjuk 

a yum.conf(5) man-oldalt is, de vizsgáljunk meg néhányat 

a legfontosabbak közül. 

Az általános (global) szakaszban a debuglevel azt határoz- 
za meg, hogy a Yum kimenete mennyire legyen bőbeszédű. 
Ennek az értéke 0-tól (nincs semmilyen kimenet) a 10-es ér- 
tékig (a legrészletesebb kimenet) terjedhet. Az 1. listán lát- 
ható az alapértelmezett beállítás, amelynek értéke 2. 
Amennyire én tudom, ez a debuglevel értéke csak a szab- 
ványos kimenetet érinti, vagyis nincs hatással a Yum napló- 
fájljára, amelynek a helyét a logfile értéke határozza meg. 
Most ezt az értéket mégis 4-re szeretném átállítani, amely 
értéket úgy kaptam meg, hogy egy kicsit eljátszadoztam 

a yum parancs -d paraméterével. Például a (yum -d 4 yum- 
parancsok) utasítással ugyanazt a hatást érhetjük el és ez 

a beállítás felülbírálja a debuglevel értékét. 

Szintén az általános szakaszban találjuk a pkgpolicy vál- 
tozót, amely azt határozza meg, hogy egy adott csomag 
melyik változatát használja a program, amikor az több 
[server] blokkban is előfordul. A distroverpkg változó 

a helyi kiadás-fájl csomag (release file package) nevét adja 
meg A kiadás fájl, amely például /etc/fedora-release vagy 
letc/redhat-release lehet, a Linux rendszercsomagunk nevét 
és változatszámát tartalmazza. 

Minden egyes [server] blokk egy RPM-halmazt határoz 
meg. Jobban örülnék neki, ha ezeket inkább [package-typel] 
blokkoknak neveznék, ugyanis nem a kiszolgáló, hanem az 
RPM-csoport az, ami ezeket megkülönbözteti. Egyetlen blokk 
is tartalmazhat több kiszolgálóra mutató URL-t. Az 1. listában 
a [base] blokk egyetlen URL-t tartalmaz, amely a fő Fedora 
tárhelyre, a 5 httoAwww.fedora.redhat.com címre mutat. 
Azok a Fedora-tükrözések, amelyek ugyanezeket az RPM- 
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meg ugyanebben a szakaszban. A [server] blokk bármely 
sorában használható két változó: a $releasever, amely 

a használt Linux rendszercsomag verziószámát adja meg, 

és a $basearch, amely a rendszerünk processzorát sorolja 

a megfelelő processzorcsaládba. A processzorcsaládok itt 

a legáltalánosabb értelemben szerepelnek, ebben az összefüg- 
gésben például az Athlon processzorok az i386 család tagjai. 
Lehet, hogy a Yum RPM-ünk által telepített /etc/yum.conf 
fájl rendben működik, de az 1. listában látható alapértelme- 
zett 5 http:/fedora.redhat.com... hivatkozásokat legalább 
egy tüköroldalra mutató hivatkozással kell kibővítenünk. 
Ezzel minimálisra csökkenthető a veszély, hogy egy kiszol- 
gáló elérési problémái miatt a frissítési folyamatunk nem 
sikerül. Ne feledjük a böngészőprogramunkkal ellenőrizni, 
hogy a yum.com fájlhoz hozzáadott hivatkozások mind- 
egyike egy olyan könyvtárra mutat, amely tartalmaz egy 
headers nevű könyvtárt is. Arra is ügyeljünk, hogy a meg- 
adott URL végére kitegyük a záró perjelet. 

Az 1. listával kapcsolatos másik említésre méltó dolog, hogy 
hiányzik egy fontos Iserver] szakaszbeli beállítás, mégpe- 
dig a gpgcheck. A 2. listán láthatunk egy javított [base] 
blokkot, amely használja ezt a lehetőséget. 

A gpgcheck-1 beállítással azt érjük el, hogy a Yum minden 
letöltött RPM-csomagban ellenőrzi a GnuPG aláírást. 
Ahhoz, hogy ez működjön, szükségünk van a megfelelő 
GnuPG-kulcsok RPM-adatbázisunkba történő befoglalására. 
A Fedora Core 1 rendszereknél ezek a kulcsok a fedora- 
release csomag részeként már a rendszerünkre települtek. 
Ezeknek az RPM-adatbázisba történő másolásához a követ- 
kező parancsot kell futtatnunk: 


rpm --import /usr/share/doc/fedora-release-1/ 
5 RPM-GPG" 


Az rpm --import parancs URL-t is elfogad paraméterként, 
így ha a Yum-forrásunk GnuPG-kulcsa a hálózaton keresz- 
tül hozzáférhető, az alábbi formát használhatjuk: 


rpm --import 
http: //your . distro.homepage/GPGsignature 


amelyben a http: //your. distro.homepage/GPGsignature 
részt a megfelelő valós hivatkozással kell helyettesítenünk. 
Úgy tűnhet, hogy ezzel csak bonyolítjuk a dolgot, pedig 
érdemes használni ezt a beállítást. Az évek során számos 
Linux-terjesztéssel foglalkozó oldalról töltöttek le a gya- 
nútlan felhasználók trójai programokkal vagy egyéb 
finomságal" fertőzött programcsomagokat. Ezeknek a ki- 
védésére a legmegfelelőbb eszköz az RPM GnuPG aláírá- 
sokat támogató tulajdonságának a kihasználása. 

A 2. listában eszközölt másik említésre méltó változtatás, 

a failovermethod-proirity változó megadása, amely arra 
utasítja a Yum-ot, hogy a listában felsorolt URL-eket sorrend- 
ben, a legfelsőtől lefelé haladva próbálja felhasználni. Az 
alapértelmezett viselkedés a fai lovermethod-roundrobin, 
amely beállítás hatására a Yum a felsorolt hivatkozások kö- 
zül véletlenszerűen választ ki egyet. Én személy szerint 

a prioritásos működést részesítem előnyben, mert így lehe- 
tőségem van arra, hogy a közelebbi, gyorsabb tükrözéseket 
tegyem az elsődleges helyekké. 
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3. lista Frissítések ellenőrzése (a kimenet az olvasható- 
ság érdekében enyhén rövidítve és formázva lett) 


[rootGiwazaru-fedora etc]$ yum check-update 
Gathering header information fileC(s) from 
server(s) 

Server: Fedora Core 1 - 1386 - Base 

Server: Fedora Core 1 - 1386 - Released Updates 
Finding updated packages 

Downloading needed headers 

getting /var/cache/yum/updates-released/headers/ 
5 coreutils-0-5.0-34.1.i1386.hdr 


Name Arch Version  Repo 
XFree86 1386 4.3.0-55 updates- 
released 
XFree86-100dpi-fonts 1386 4.3.0-55 updates- 
released 
XFree86-75dpi-fonts i386 4.3.0-55 updates- 
released 
XFree86-Mesa-libGL 1386 4.3.0-55 updates- 
released 


A Yum önműködő futtatása 

Elérkeztünk a könnyű részhez, a yum parancs használatá- 
hoz. A Yum futtatásának két módja létezik, az egyik, hogy 
kézzel elindítjuk a parancssorból, a másik pedig, hogy az 
letcfinit.d/yum indító parancsfájl segítségével önműködővé 
tesszük az indítást. Ha engedélyezett — ezt a chkconfig 
--add yum parancs futtatásával magunknak kell megten- 
nünk -, akkor ez a parancsfájl egyszerűen ellenőrzi a fut- 
tatófájlt, amely a /var/lock/subsys/yum fájl, s amelyet 

a cron.daily feladat, a yum.cron vizsgál meg. Ha a parancs- 
fájl engedélyezett, vagyis ha a futtatófájl létezik, a cron- 
feladat először is futtatja a Yum parancsot a frissített 
Yumcsomag ellenőrzésének és telepítésének céljából, ez- 
után pedig ellenőrzi az összes többi csomag esetleges frissí- 
tését, és szükség esetén telepíti is azokat. Mindeközben 

a Yum a háttérben önműködően felold minden fontos füg- 
gőséget. Ha egy frissített csomag függ egy másik csomagtól, 
a Yum kikeresi és telepíti az a csomagot, még akkor is, ha 
korábban ez nem történt még meg. 

A legtöbb felhasználó jó hasznát veheti ennek a haté- 
kony parancsfájlnak. Ellenben ha a környezetünk meg- 
kívánja a minden részletre kiterjedő változás-ellenőrzést, 
és nem szeretnénk, hogy bármilyen új program önmű- 
ködően a rendszerünkre kerüljön, kézzel kell futtatnunk 
a Yum-ot. 


A Yum manuális indítása 

Ha csak egy listát szeretnénk kapni az elérhető frissítésekről 
anélkül, hogy bármit is feltelepítenénk, használjuk a yum 
check-update parancsot (3. lista). 











Egyetlen frissítés telepítéséhezés az összes olyan frissítés 
végrehajtásához, amire a függőségek miatt szükség van, 

a yum update csomagnev parancsot használhatjuk, pédául 
yum update yum. 

Ezzel valójában csak magát a Yum csomagot frissítjük. Ha 
tényleg elérhető a Yum egy frissített csomagja, a rendszer 

a folytatásra és telepítésre buzdít. Amennyiben a Yum-ot 
egy parancsfájlból hívjuk, és azt szeretnénk, ha az összes 
feltett kérdésre önműködöen -y legyen a válasz, használjuk 
a -y kapcsolót: 


yum -y update yum 


A check-update parancs, vagyis a Yum parancs megfelelő 
formájának futtatása, nem kötelező a frissítések telepítése 
előtt. Ha úgy tetszik, használhatjuk közvetlenül a yum 
update parancsot is — ez ugyanazokat az ellenőrzéseket 
végrehajtja, mint a yum check-update. 

Az utolsó mintaként bemutatott parancsban egyetlen fris- 
sítendő csomagot, a yum-ot adtuk meg. A rendszerünkön 
lévő összes telepített csomag frissítésének kezdeményezé- 
séhez mindössze el kell hagynunk az utolsó paramétert, 

a csomag-meghatározást: yum update. 

Miután a Yum ellenőriz minden frissítési lehetőséget, és ki- 
számolja a függőségeket, bemutat egy listát azokról a frissí- 
tésekről, amelyeket le szeretne tölteni. Ha nem használtuk 
a -y lehetőséget, kérdést kapunk, hogy tényleg le szeret- 
nénk-e tölteni és telepíteni az összes felsorolt csomagot. 

A teljesség kedvéért íme egy jutalomtipp: új csomagokat 








is telepíthetünk a Yum segítségével — mint ahogy erre eset- 
leg már rá is jöttünk. Bármelyik csomag esetében, amelyet 
tartalmaz az /etc/yum.conf fájlban felsorolt források valame- 
lyike, használhatjuk a yum instal] csomagnev parancsot 

a kérdéses csomag legfrissebb változatának telepítéséhez, 
kiegészítve azokkal, amelyektől függő helyzetben van. 
Például a vsftpd nevű FIP-kiszolgáló csomag telepítéséhez 
a következő parancsot futtatnánk: yum insta11 vsftpd. 


További információk 

Amennyiben a Yum használatával kapcsolatban bármilyen 
problémánk adódna, a hálózaton keresztül bőséges leírás 

— köztük két kitűnő GYIK áll rendelkezésre. Erre vonatko- 
zóan lásd a hálózaton keresztül elérhető források jegyzékét. 
Ha az on-line dokumentáció sem segít, rendelkezésünkre 
áll a Yum levelezőlistája is. Mielőtt azonban feladnánk egy 
kérdést, ne mulasszunk el a problémánkra vonatkozóan 
egy-két keresést feladni a Google keresőben. E cikk írása 
közben számos olyan kérdéssel találkoztam a Yum levelező- 
listáján, amit a Google segítségével meg tudtam oldani. 
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RPIM tranzakciók és visszavonás 


Ha egy frissítés jól működik, néhány új képességhez, vagy jobb 
teljesítményhez jutunk. Ha azonban becsúszik egy hiba, az egész 
hétvégénk tönkremehet. Nézzük meg, hogyan térhetünk vissza 

a korábbi verzióhoz és tarthatjuk karban rendszerünket. 


ányszor fordult már elő, hogy valami csodásnak 
RK ígérkező új programot telepítettünk fel, csak azért, 

hogy szinte azonnal kiderüljön: valójában egyálta- 
lán nem is akartuk felrakni? Sőt, a dolog még kellemetle- 
nebb lehet, ha a feltelepítendő programhoz jó néhány 
egyéb csomagot kell frissítenünk további párat pedig az ala- 
poktól felraknunk. Ha a dolgokat az eredeti állapotba sze- 
retnénk visszaállítani, több forrásból kellene előkeresnünk 
a továbbfejlesztett csomagok korábbi verzióját, visszalépni 
ezekre a verziókra, valamint leszedni minden újonnan fel- 
rakott csomagot. Természetesen ha nem tartjuk rendszere- 
sen nyilván milyen új csomagokat változtattunk meg és mi 
is volt a korábbi verzió, a dolgok még rosszabbra fordulhat- 
nak. Hát nem lenne sokkal egyszerűbb, ha csak megnyom- 
nánk egy gombot, vagy kiadnánk egy parancsot, és máris 
visszatérhetnénk a régi verzióhoz? 
Néhány környezetben a frissítés előtti állapothoz való 
visszatérés nem csupán lehetőség, hanem egyenesen kö- 
vetelmény. A telekommunikációs cégek felszerelésének 
fejlesztésekor például a programozó és alkatrész szolgálta- 
tó cégeknek minden fejlesztést egy karbantartási ablaknak 
nevezett, korlátozott időszakban kell elvégezniük. Ugyan- 
ebben a karbantartási ablakban a továbbfejlesztés során 
bekövetkezett valamennyi változtatást vissza is kell tudni- 
uk állítani. Ha nem sikerül a karbantartási ablakon belül 
befejezni a műveletet, annak súlyos pénzügyi következ- 
ményei lehetnek. 


Frissítés és helyreállítás, nehézkesen 

Bármennyire is kívánatos lenne az RPM-ek automatikus 
visszaállítása egészen mostanáig nem volt erre lehetősé- 
günk. Az igazság kedvéért hozzá kell tennünk, hogy az 
RPM támogatta a csomagkészletek visszafejlesztését 
(downgrade). Például, ha a foo-1-1 RPM csomagról a foo-1-2 
verzióra fejlesztettük, az rpm parancsot az --oldpackage 
kapcsolóval futtatva visszaléphetnénk a korábbi verzióhoz; 
valahogy így: 


ff rpm -uvh --oldpackage foo-1-1.1386.rpm 
Preparing... TEHÁT ETELE AHÁ 
[100551 
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Uupgrading. .. 
1:foo FÁHÁHÁHÁHÁ ÁÁÁÁ ÁÁÁÁ AA [10075] 
Amennyiben a foo-1-2 fejlesztéséhez nem volt szükségünk 
semmilyen további RPM csomagra, az --oldpackage kap- 
csoló kiválóan működik. Mindössze a korábbi foo-1-1 RPM 
csomagot kell megtalálnunk és kész is vagyunk. Azonnal 
megváltozik a helyzet azonban, ha a foo-1-2 más csomagok- 
tól is függ, amelyeket így szintén fel kellett tennünk. Ez 
esetben elő kell keresnünk ezeket az RPM-eket különféle 
helyekről - a telepítő lemezről, a terjesztésünk hibajegyzék 
oldaláról, egyéb RPM tárhelyről vagy a projektek web- 
lapjairól. 
Miután levadásztuk az összes szükséges RPM-et , vala- 
mennyit vissza kell fejlesztenünk majd letörölnünk a fris- 
sen telepítetteket. Ha ezt fordított sorrendben csinálnánk, 
letörölnénk a frissen feltelepített RPM-eket és csak aztán 
fejlesztenénk vissza a frissített RPM-eket, akkor az RPM hi- 
baüzenetekkel örvendeztetne meg bennünket, miszerint 
ezekre a csomagokra a foo-1-2 csomagnak szüksége van. 
Tömören: ez idáig több RPM csomag visszaállítása igencsak 
nehézkes volt, és tele hibalehetőségekkel. 


Tranzakció alapú visszavonás és rendszermentés 

2002 elején, Jeff Johnson, az RPM aktuális gazdája, megpró- 
bált ellenszert találni erre a visszavonási problémára és az 
RPM 4.0.3-as változatában bevezette a tranzakció alapú 
visszavonási képességet. Ez már magában hordozta az RPM 
csoportok automatikus visszavonásának lehetőségét. Akár- 
csak más új képességek, ez is kicsit elnagyoltra sikerült, és 
-— az RPM levelezési (rpm-listoredhat.com) lista néhány le- 
velétől eltekintve -, teljesen dokumentálatlan volt. Az el- 
múlt másfél évben a tranzakció alapú visszavonás folyama- 
tosan fejlődött. A Red Hat 9-el érkező, jelenlegi 4.2-es RPM 
kiadásban például már teljesen használható ez a funkció. 


A tranzakció alapú RPM visszavonás működési elve 

A színfalak mögött az RPM minden feltelepített RPM cso- 
portot egy-egy tranzakciónak tekint. Ez igaz, ha egyetlen 
RPM-et telepítünk fel (egy RPM tranzakciója) és akkor is, 
ha több RPM-et teszünk fel egyszerre. Minden ilyen tranz- 

















KÖLL ETERE ti Configuration 


sz. 6 u j 1-ajizi 
General ! Retrieval / installation [ Package Exceptions ] 


Package Retrieval Options 
L ] Do not install packages after retrieval 














(z] Do not upgrade packages when local configuration file has been modified 
L] Retrieve source RPM along with binary package 
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ackage Verification Options 
Use GPG to verify package integrity 
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Package Installation Options 
After installation, keep binary packages on disk 
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1. ábra RPM visszavonás engedélyezése az up2date programban 


akció egyedi tranzakció azonosítót (TID) kap. Ahogy az 
RPM felkerül és frissül, bejegyzését az RPM adatbázisban 
megjelöljük a telepítésekor felhasznált TID azonosítóval. 
Ezáltal az RPM nyomon tudja követni, hogy mely RPM cso- 
magokat mely tranzakciók során telepítettük és frissítettük. 
Ha az RPM visszavonja a tranzakciócsoportot, el kell tudnia 
érni a tranzakció végrehajtása idején a rendszeren lévő cso- 
magokat. Ezt a problémát úgy oldja meg, hogy törlés előtt 
valamennyi csomagot újracsomagolja, majd eltárolja őket 

a repackage könyvtárban (alapértelmezés szerint, /var/ 
spool/repackage). Az újracsomagolt csomagok az RPM által 
kezelt és a törlés pillanatában a rendszeren található vala- 
mennyi állományt, a régi RPM-ek fejléceit illetve a régi 
RPM-el kapott parancsfájlocskákat (scriptlets) tartalmazzák. 
Felmerül a kérdés, ugyan mi köze mindennek a frissítések- 
hez? Ha ugyanis frissítünk egy RPM csomagot, attól még 
nem töröljük le — nem igaz? De bizony, letöröljük. Ugyanis 
az RPM frissítése két részből áll: az új csomagot feltelepít- 
jük, a régit pedig letöröljük. Ennek megfelelően, valahány- 
szor frissítünk egy csomagcsoportot, az RPM előbb újracso- 
magolja az összes frissítendő csomagot, ezután telepíti az 
újakat, végül pedig letörli a régieket. Amikor az RPM újra- 
csomagolja a régi csomagokat, egyúttal meg is jelöli azokat 
a futó tranzakció TID azonosítójával. Ennek köszönhetően 
többé nem kell a netet, tárolókat, vagy mentéseket böngész- 
ni a frissített csomagokat keresendő. Mivel az újracsomagolt 
csomagok azokat az állományokat tárolják amelyek a frissí- 
tés idején a rendszerünkön voltak, a beállításfájlokat sem 
kell mentésekből visszaállítanunk. Mellékhatásként az újra- 
csomagolt csomagban található állományok md5 ellenőrző- 
összegei valószínűleg hibásak lesznek, ugyanis az RPM eze- 
ket nem számítja ki újra az újracsomagolt csomag létreho- 
zása során. Szerencsére ez a tranzakciók visszaállításakor 
nem okoz gondot az RPM-nek, de ha közvetlenül szeret- 
nénk használni csomagokat használnunk kell a --nodigest 
kapcsolót. 

Az RPM-nek a repackage könyvtár feltöltése után a csoma- 
gok visszaállításához már csak a visszaállítás célpontjára 
(azaz a dátumra, amelyre vissza kell állni) van szüksége. 
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Az RPM a TID alapján el tudja dönteni milyen tranzakciók 
történtek rendszerünkön a visszaállítási időpont óta. Ez 
után az RPM veszi ezeket a tranzakciókat, sorba rendezi 

a legfrissebbtől a legkevésbé frissig, majd valamennyin vég- 
rehajtja a következő lépéseket: 


e — Kikeresi az összes ilyen TID jelet viselő újracsomagolt 
csomagot . 

e — Kikeresi az összes jelenleg feltelepített csomagot ame- 
lyet ilyen TID jelöl de nincsen megfelelő újracsomagolt 
csomagja. 

e  Felépíti a visszaállítási tranzakciót. Az újracsomagolt 
csomagok ebben mint telepítendők szerepelnek, a meg- 
felelő újracsomagolt csomag nélküli csomagok pedig 
törlendő elemként. 

e  Lefuttatja a frissen elkészített visszaállító tranzakciót. 


Ezeket a műveleteket ismételgetve a legfrissebbtől a céldá- 
tumhoz legközelebbi vagy azzal egyező dátumú csomagig, 
az RPM végiglépked a visszaállítási időpont óta bekövetke- 
zett valamennyi tranzakción és eltünteti hatásukat. 


Hogyan használhatjuk a tranzakció alapú 


RPM visszaállítást 

Azt gondolhatnánk, hogy ez elég bonyolult folyamat, de 

a tranzakció alapú visszaállítás valójában rendkívül egysze- 
rű. Példaként telepítsünk egyetlen RPM csomagot majd 
vonjuk vissza. A leglényegesebb dolog amire emlékeznünk 
kell, hogy valahányszor frissítünk vagy törlünk egy csoma- 
got, soha ne felejtsük el előtte az RPM-nek kiadni a régi 
csomag újracsomagolását végző parancsot. Ehhez 

a --repackage kapcsolót kell használnunk: 


í rpm -Uvh --repackage foo-1-2.noarch.rpm 


Preparing... 0 ttátttátátátátátttátátttátát tát áttett átkát átkát át átt [100761] 
Repackaging. . . 

1:foo TETHÁEETEÁ TEÁT TETTETETT TEÁK AKA Hét At tt [100751 
Uupgrading. . . 

1:foo TETEÁEETEÁETEÁ ETETETT ÁEH TETE TETTEK AHÁ [100751 


A kapcsoló hatására az RPM előbb újracsomagolja a régi 
csomagot, majd frissít az új változatra. Törléskor szintén 
meg kell adnunk a --repackage kapcsolót, valahogy így: 


$ rpm -e --repackage foo 


Az RPM törléskor nem mutat semmilyen kimenetet, de ha 
törlés után belenézünk az újracsomagolási könyvtárba, 
megtalálhatjuk az újracsomagolt csomagokat. 

Az RPM tranzakció visszavonására a --rollback kapcsolót 
használjuk, amelyet a visszavonás időpontja követ. 

A visszavonás időpontja lehet valódi dátum vagy olyan ki- 
fejezés mint ,egy órával ezelőtt" (a dátumértelmező ugyan- 
olyan formátumot használ, mint a cvs(1) parancs -D kap- 
csolója). Így, ha már eltelt egy óra a foo telepítése óta, és 
úgy döntünk, még sincs rá szükségünk, a következő sort 
gépeljük be: 


tf rpm -uvh --rollback "2 hours agol 
Rollback packages (-1/-1) to 
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Thu Jul 31 23:26:52 2003 C(Ox3f29ddfc): 
Preparing... 0 ttttátttátátttátátttátátttátátttátátttátátátátátátátát 100751] 
1:foo ELTALÁLT TÁLALT TET TEA Á Abt Átátt [3329] 


A Rollback packages (41/-1) kimenet mutatja, hogy 
az RPM egy darab csomagot (az előző verziót ) fog fel- 
venni, és egy csomagot (a jelenleg telepített verziót) 
fog törölni. 


Hogyan készítsünk visszavonás alapú rendszert? 

A tranzakció alapú visszavonás csak annyira használható 
amennyire az újracsomagolt csomagjaink tárháza. A leg- 
gyorsabban úgy tudjuk elrontani a dolgot, ha valamit 

a --repackage kapcsoló nélkül frissítünk vagy törlünk. 
Márpedig saját tapasztalataim szerint rendkívül könnyű 
elfeledkezni erről a kapcsolóról. Ezért aztán ha tranzakció 
alapú visszavonást szeretnénk hasz- 
nálni, érdemes úgy beállítani az RPM- 
et, hogy automatikusan újracsoma- 
goljon minden törlést. Állítsuk be 

a9 repackage all. erasures makrót 
a 1-re a /etc/rpm/macros állományban. 
Ha a fájl nem létezik nyugodtan 
hozuk létre: 


9.repackage all erasures 1 


Alapértelmezés szerint az RPM nem 
von vissza frissen telepített csomago- 
kat; azaz nem töröl le olyan csoma- 
gokat, amelyek a frissítésünk idő- 
pontjában még nem voltak a rend- 
szeren. Valószínűleg nem szeretnénk, 
ha ez lenne az alapértelmezett műkö- 
dési forma, úgyhogy meg kell mon- 
danunk az RPM-nek, hogy engedélyezze a törlést. Állítsuk 
a 7 unsafe rollbacks makrót olyan dátumra, amelyen 
túl már nem szeretnénk, ha az RPM visszavonáskor teljes 
törlést végezne. Erre a célra például nagyon jól megfelel 
az az időpont amikor a teljes rendszert feltelepítettük. 

A dátumot epoch után másodpercben kell megadni. Az 
epoch óta eltelt másodpercek számát a date parancs segít- 
ségével állíthatjuk elő: 


date --date—-"2003/8/1" 4965 
1059710400 


(a dátumot átírtuk magyar sorrendre, helyes Local beállítású 
UNIXon ennek mennie kell. — a szerk.) 


Ha például azt szeretnénk megadni az RPM-nek, hogy 

a 2003/8/1 előtti csomagokat ne távolítsa el teljesen (lásd 
a fenti példában használt dátumot), a következő sort kell 
a /etc/rpm/macros fájlba írnunk: 


7 unsafe rollbacks 1059710400 
Egyetlen dolog maradt még, amit esetleg érdemes átállítani, 


mégpedig az, hogy hol tárolja az RPM az újracsomagolt 
csomagokat. Tehetjük ezt például azért, hogy elegendő 
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hellyel rendelkező partícióra helyezzük őket. Az újracsoma- 
golási könyvtár megváltoztatásához aX repackage dir 


sé gő jó 


tanunk: 
9. repackage dir /my rp. repository 


Készítettünk tehát egy rendszert, amely automatikusan új- 
racsomagolja a törléseket (így se mi, se más nem felejti el), 
visszavonáskor törli az újonnan felrakott csomagokat (de 
nem törli az egész rendszerünket) és a nekünk megfelelő 
helyen tárolja az újracsomagolt állományokat. 


RPM tranzakciók visszavonása up2date segítségével 
Red Hat 9 alatt az RPM tranzakció alapú visszavonási 
módszerét használva az up2date program is támogatja 

a visszavonásokat. Amennyiben be 
akarjuk állítani a tranzakció alapú 
visszavonást mindössze az up2date- 
config programot kell lefuttatnunk, 
rákattintanunk a Retrieval/ 
Installation fülre, majd kiválaszta- 
nunk az Enable RPM rollbacks jelölő- 
négyzetet (1. ábra). Magát az RPM-et 
az előző szakaszban leírtak szerint 
kell beállítanunk. Az RPM és az 
up2date program beállítása után 
rendszerünket az up2date segítségé- 
vel frissítve, az RPM frissítés előtt el- 
készíti az RPM-ekhez tartozó újracso- 
magolt csomagokat. 

Az ismert visszavonási időpontok 
listáját a következő parancs segítsé- 
gével kapjuk meg: 


upzdate --list-rollbacks 
Hatására valami ilyen listát kapunk: 


f up2date --list-rollbacks 
install time: Sun Jul 27 20:49:55 2003 
tid:1059353395 

[-] g00-1.0-1.0: 


install time: Tue Jul 29 20:44:25 2003 
tid:1059525865 
[-1 foo-1-2: 


Ez a parancs akkor is jól jöhet, ha egyébként nem használ- 
juk az up2date parancsot, ugyanis az rpm parancs nem ké- 
pes ilyen adatok megjelenítésére. 

A tranzakció visszavonását a --undo kapcsolóval végezzük, 
amely az utoljára telepített tranzakciót vonja vissza. Egy- 
szerűen adjuk ki a következő parancsot: 


ff up2date --undo 
Amennyiben több tranzakciót szeretnénk visszavonni, fut- 


tassuk többször a parancsot. A grafikus felületen keresztül 
nem tudunk visszavonást kérni. 





Az RPM általában a legkisebb fáradtság elvén dolgozik, az- 
az, ha egy vagy több RPM csomagot nem tud feltelepíteni, 
a tranzakcióban található egyéb csomagok ettől még felke- 
rülnek. Bizonyos környezetekben ez a kívánatos viselkedés, 
máskor azonban sokkal jobb lenne ha automatikusan 
visszavonná a hibás tranzakciót. Minthogy én ilyen környe- 
zetben dolgozom (telekommunikáció), írtam egy automati- 
kus visszavonás (auto-rollback) foltot. Ezzel a folttal az 
RPM-et úgy is be lehet állítani, hogy hibás tranzakció ese- 
tén automatikusan vonja vissza a hibás tranzakciót. 
Amennyiben az RPM a feopost parancsfájlban okoz hibát, 
sajnos az RPM-et hátrahagyja; remélhetőleg ez hamarosan 
ki lesz javítva (van kedve valakinek foltozni?). Ha használni 
szeretnénk ezt a funkciót, a foltot (vagy a foltozott RPM- 
eket) a 5 http: Wwww.lee.k12.nc.us/-joden/misc/patches/ 
rpm címről tölthetjük le. Az automatikus visszavonás folttal 
rendelkező RPM rendszerünk telepítése után be kell állíta- 
nunk az RPM-et, hogy használja az automatikus visszavo- 
nás képességet. Ehhez az /etc/rpm/macros állományt kell 
átszerkesztenünk, felvéve a következő makródefiníciót: 


9. rollback transaction on failure 1 


Ezután ha majd legközelebb telepítünk illetve frissítünk 
egy RPM csoportot, és az egyik hibásan sikerül, akkor az 
RPM automatikusan visszavonja a hibás tranzakciót, ki- 
véve persze amelyik a Xpost parancsfájl futtatása során 
okozott hibát. 








05 uialás 

A tranzakció alapú RPM visszavonás hatékony módszer 
az RPM frissítések előtti helyzet visszaállítására. Egy biztos 
alapot ad, melyre építve a rendszerfrissítő programok 
(up2date, yum és az apt-get) automatikus visszavonási 
képességet nyújthatnak a felhasználónak. Ugyanakkor 

a tranzakció alapú visszavonást nem igényli mindenki. 
Jeff Johnson szavaival élve ,a --rollback kapcsoló... töké- 
letes rendszeradminisztrációt igényel és inkább gépezet 
mint rendszabály." A tranzakció alapú visszavonás 
mindent-vagy-semmit jellegű dolog. Figyelni kell rá, hogy 
minden törlés újracsomagolódjék, hiszen az RPM tranzak- 
ció visszavonási képessége csak annyira használható 
amennyire az újracsomagolt csomagkészlet. A rendszer- 
gazdának biztosítania kell némi külön tárhelyet az újracso- 
magolt csomagok számára. Végül, az tranzakció alapú 
RPM visszavonás folyamatos fejlesztés alatt áll. Amennyi- 
ben szeretnénk, hogy az RPM rendszerífrissítéseinket gyor- 
san vissza tudjuk vonni, valószínűleg pontosan ez az amit 
a doki ajánl. 


Linux Journal 2004. május, 121. szám 


James Olin Oden (jodenXlee.k12.nc.us) prog- 
ramozó a Tekelec-nél. UNIX-típusú rendszereket 
kezelt és alattuk fejlesztett több mint egy évti- 
zede. Ő a Tech Tracker (tt.lee.k12.nc.us) e Web 
alapú IT-követő rendszer alkotója is. 


Szavazz a CD-mellékletről! 


Tavasszal , Szerkeszd te is a Linuxvilágot!" 

felhívással egy on-line kérdőív kitöltésére kértük 
olvasóinkat honlapunkon, melynek értékelése a júliusi 
számban jelent meg (a bővebb változat honlapunkon is 
elérhető http://www.linuxvilag.hu/hir/1022/711.html]). 


Az eredmény alapján készítettünk egy tervezetet a CD- 


melléketre vonatkozó változtatásokra. Ennek megvaló- 


www.linuxvilag.hu 


sításáról a Ti szavazataitok fognak dönteni, ezért kérünk 
mindenkit, hogy válaszoljon 3 kérdésre ezen az oldalon: 


http://vww.linuxvilag.hu/kerdoiv. cd 
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LSB alkalmazásokat készítése 


Ne kössük Linux programunkat egyetlen terjesztéshez. Tegyük mindenhol futtat- 
hatóvá egy valamennyi nagyobb terjesztés által használt szabvány segítségével. 


Linux Szabványos Alap (Linux Standard Base, 
A LSB) az alkalmazás és a futási környezet közötti 

felületet szabványosítja. Több terjesztés szerzett 
már futtatási környezetéhez ilyen bizonyítványt. Ebben 


a cikkben lépésről lépésre megismerkedhetünk az LSB 
csatolófelülettel. 


Az LSB eredete 

Az LSB-Projekt 1997-ben alakult, hogy megoldást találjon 
az egyre komolyabbá váló kompatibilitási problémákra. 

A különféle terjesztések eltérő élvonalbeli programverzió- 
kat használtak és azokat eltérő opciókkal fordították le. Kö- 
vetkezésképpen gyakran előfordult, hogy az egyik terjesz- 
tésen lefordított program nem futott a másik terjesztés alatt. 
Még ennél is nagyobb gondot jelentett, hogy időnként az 
alkalmazások akkor sem működtek, ha ugyanazon terjesz- 
tés másik verziójáról volt szó. 

Az LSB célja eredetileg az volt, hogy egységes megvalósítási 
gyűjteményt készítsen, amely majd a GNU/Linux rendszer 
alapjául szolgálhat. A megvalósítási gyűjteményhez lejegy- 
zett specifikációt készítettek. Sok terjesztés azonban nem 
fogadta kedvezően ezt az ötletet, ugyanis saját alapprog- 
ramjuk fejlesztésébe komoly erőforrásokat fektettek, amit 
versenyelőnyként értékeltek. 

Az érdekelt felek aztán megváltoztatták az LSB Projekt 
alapvető céljait, hogy ezáltal az egész közösségre nézve el- 
fogadható megoldást találjanak. Ezzel elsődleges szerepet 
kapott a megvalósítással szemben az írott specifikáció, így 
az LSB irányadó képesség/verzió párok helyett inkább visel- 
kedési útmutatóvá vált. Az új megoldást három fő ág jel- 
lemzi: az írott specifikáció, amely a rendszer viselkedését 
adja meg; a formális tesztkészlet, amely a specifikációnak 
megfelelő megvalósítást ellenőrzi; és a minta-megvalósítás, 
amely a specifikációra mutat példát. 


Az LSB szerkezete 

Az LSB specifikáció jelenleg egy gLSB nevű általános rész- 
ből és az archLSB gépfüggő részből áll. A gLSB tartalmazza 
a gépek (architektúrák) közös jellemzőit; nagyon igyekez- 
tünk mindent a gLSB-ben megadni. Az archLSB tartalmaz- 
za mindazon részleteket, amelyek processzortípusonként 
eltérőek, például a gépi utasításkészletet és a C könyvtár 
szimbólum verzióit. 
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Az LSB tartalma 

Amennyire csak lehetséges, az LSB már létező szabványok- 
ra épül, ideértve a POSIX-bál kifejlődött Single UNIX Speci- 
fikációt (SUS), a System V Interface Definition (SVID) és 

a System V Application Binary Interface (ABI) szabványo- 
kat. Az LSB az ABI szabvány ELF definícióit és a SUS csato- 
lófelület viselkedési irányelveit használja. A formális listá- 
ban egyrészt azt határozza meg, hogy mely csatolófelületek 
mely könyvtáron keresztül érhetőek el, másrészt pedig 

a hozzájuk tartozó adatszerkezeteket és állandókat is. A je- 
lenleg érvényben lévő könyvtárak listáját a , Linux Szabvá- 
nyos Alapkönyvtárak" széljegyzetben találjuk. 

Az LSB ABI részén kívül az ajánlás felsorolja az alkalmazá- 
sokhoz tartozó parancsfájlokban felhasználható parancsokat 
is. Egyben azt is kimondja, hogy az alkalmazásnak tartania 
kell magát a Fájlrendszer Hierarchia Szabványhoz (FHS). 

Az LSB egyik kiegészítője a csomagolási formátum. Az LSB 
kimondja, hogy a csomagformátumnak az RPM fájlformá- 
tum csoport tagjának kell lennie, ugyanakkor nem szabja 
meg, hogy a terjesztésnek kötelező RPM alapúnak lennie. 
Mindössze azt köti ki, hogy valamilyen módon helyesen 

fel kell tudni dolgoznia az RPM formátumú állományokat. 
Az utolsó említésre méltó dolog a parancsértelmező neve. 
Az alkalmazás indításakor a parancsértelmező indul első- 
ként és felelős az a program többi részének valamint a meg- 
osztott könyvtáraknak a folyamat címterébe töltéséért. Ha- 
gyományosan a /lib/ld-linux.so.2 -t használják, de az LSB 

e helyett a /lib/ld-Isb.so.1 nevet határozza meg az IA32 
rendszereken. A /lib/Id-arch-Isb.so.1 nevet általában más 
géptípusokhoz használják. Ezzel az operációs rendszernek 
lehetőséget adunk, hogy ha a folyamatfeldolgozás elején 
valami különleges dologra lenne szükség, az alkalmazásnak 
helyes futási környezetet biztosíthasson. A parancsértelme- 
zőt a következő GCC paraméterrel tudjuk megváltoztatni: 


-w1 , --dynami c-Tinker-/1ib/1d-1sb.so.1 
Az itt bemutatandó eszközök mindezt megteszik helyettünk. 


Az LSB fordítási környezet 

Az emberek rég felfedezték, hogy a kódváltoztatások sokkal 
egyszerűbbek és olcsóbbak ha a fejlesztési folyamat korábbi 
szakaszában kerülnek elő. Ezt szem előtt tartva az LSB Pro- 











jekt létrehozott egy fordítási környezetet, amely segít az 
LSB szabványú alkalmazások készítésében. A fordítási kör- 
nyezetben találunk néhány tiszta fejlécállományt, stub 
könyvtárakat és fordító csomagolásokat (wrappers). 

Az LSB e definíciók nagy részét adatbázisban tárolja. Az 
egyébként kézzel csak nagyon nehezen szerkeszthető speci- 
fikációs részleteken felül képesek vagyunk olyan tiszta fej- 
léc fájlokat és stub könyvtárakat készíteni, amelyek kizáró- 
lag az LSB által meghatározott elemeket tartalmazzák. Az 
adatbázis segítségével biztosíthatjuk, hogy a változtatások 
és bővítések során az eszközök és a specifikációk folyamato- 
san szinkronban maradjanak. A telepítendő csomagok listá- 
ját a Linux Szabványos Csomagok" széljegyzetben találjuk. 
Az LSB szabványnak megfelelő alkalmazás készítésekor az 
első lépés, hogy a kódot az LSB fejlécekkel fordítsuk le. Ha 
a fordítás sikertelen, akkor valószínűleg valamilyen LSB-n 


kívüli elemet használunk. Ez persze nem feltétlenül végze- 
tes, de mindenképpen érdemes rá különös figyelmet fordí- 
tani. Az LSB fejlécek az /opt/Isbdev-base/include könyvtár 
alá települnek. Egy gyors teszt kedvéért adjuk meg a GCC- 
nek a -I/opt/Isbdev-base/include kapcsolót és figyeljük 
meg mi történik. Ezt és néhány további lépést a később is- 
mertetésre kerülő fordító-csomagolás elvégzi helyettünk. 

A kód lefordítása után a következő lépés és teszt a kód vég- 
leges alkalmazássá szerkesztése (link-elése). Általában ez 

a lépés valahogy így néz ki: 
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gcc -o appl obji1.o obj2.o -Ifoo 


Az LSB stub könyvtárak a /opt/Isbdev-base/lib könyvtárban 
találhatók, melyet a fordítónak a -L kapcsolóval tudunk 
megadni. Ezeket a stub könyvtárakat csak fordításhoz hasz- 
náljuk. Futásidőben általában a rendszer saját könyvtárait 
fogjuk felhasználni. Akárcsak az előbb, a később bemutatás- 
ra kerülő fordító csomagolás mindezt elvégzi helyettünk. 
Az alkalmazás összeszerkesztése után az Idd parancs segít- 
ségével meg tudjuk nézni milyen megosztott könyvtárakat 
használtunk fel. Ezen a ponton az LSB-ben megadott (és 

a ,Linux Szabványos Alap könyvtárak" széljegyzetben fel- 
sorolt) könyvtárakon kívül semmilyen más könyvtárnak 
nem szabad megjelennie. Ha mégis ilyesmi történik, továb- 
bi lépéseket kell tennünk és statikusan kell beszerkesszük 
őket. Általában a -w1l ,-Bstatic és -WwI , -Bdynami c kapcso- 
lókkal tudjuk megadni, ha az adott könyvtárat statikusan 
szeretnénk beszerkeszteni. Mostanra már biztosan ráérez- 
tünk: a fordító csomagolás ezt is elvégzi helyettünk. 
Példaképpen, nézzük meg hogy néz ki egy tipikus xpdf 
alkalmazás: 
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ft ldd /usr/bin/xpdf 
Tibxpm.so.4 —5 /usr/x11R6/1ib/libXxpm.so.4 
Tibt1.so.1 —5 /usr/lib/Tibtl1.so.1 
Tibfreetype.so.6 —5 /usr/lib/libfreetype.so.6 
TibSM.so.6 —5 /usr/x11R6/1Tib/TibSM.so.6 
TibICE.so.6 -—5 /usr/x11R6/1ib/TibICE.so.6 
Tibx11.so.6 —5 /usr/x11R6/1ib/1ibXx11.so.6 
Tibpaper.so.1 -—5 /usr/lib/libpaper.so.1 
Tibstdcr---1ibc6.2-2.so.3 —— 
/usr/tib/libstdc-r---1ibc6.2-2.so.3 
Tibm.so.6 -5 /Tib/lTibm.so.6 
Tibc.so.6 -—5 /lib/libc.so.6 
/1Tib/ld-Tinux.so.2 -5 /Tib/ld-Tinux.so.2 


És ilyen egy LSB-nek megfelelő xpdf: 


tt Idd /opt/1sb-xpdf/bin/xpdf 
TibSM.so.6 -5 /usr/x11R6/1lib/TibSM.so.6 
TibICE.so.6 -—5 /usr/x11R6/1Tib/TibICE.so.6 
Tibx11.so.6 -35 /usr/x11R6/1lib/libX11.so.6 
Tibm.so.6 -—5 /1Tib/libm.so.6 
Tibgcc s.so.1 -—5 /Tib/Tibgcc s.so.1 
Tibc.so.6 -5 /Tib/Tibc.so.6 
/Tib/ld-Isb.so.1 -5 /Tib/ld-Isb.so.1 


A nem-LSB könyvtárak meg sem jelennek az alkalmazás fu- 
tásához szükséges könyvtárak közt, hiszen statikusan fordí- 
tottuk őket az alkalmazásba. Ez persze hátrányokkal is jár: 
az alkalmazás végrehajtható állománya nagyobb lesz, 
ugyanakkor kevésbé függ az operációs rendszertől. 


Egyszerűsítsünk 

Végül elérkeztünk az Isbcc és Isbc--- fordító csomagoló- 
hoz. A kettő valójában ugyanaz a program; egyszerűen 
csak más néven hívjuk meg őket, jelezve, hogy C vagy 
C1- 4 módot szeretnénk. Az elképzelés szerint az Isbcc-t 
használjuk ha GCC-vel fordítunk és az 1lsbc-s-- változatot, 
ha ag-t 1 fordítót használjuk. 
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A csomagoló eszköz az összes megkapott kapcsolót értel- 
mezi, majd kissé átrendezi őket. Ez után néhány további 
kapcsolót is beiktat, hogy a normál rendszerkönyvtárak 
előtt az LSB szerinti fejléceket és könyvtárakat érjük el. Az 
eszköz felismeri a nem-LSB könyvtárakat is, és kikényszeríti 
statikus fordításukat. 

Minthogy az LSB-által nyújtott fejlécek és könyvtárak a ke- 
resési útvonal elejére kerültek, általában biztonságosan 
használhatunk nem LSB alapú könyvtárakat is. Azért per- 
sze nem árt, ha megnézzük, nem függenek-e valamitől, 
amit szándékosan hagytak ki a LSB fejlécek és könyvtárak 
közül, illetve vigyázni kell arra is, hogy statikusan szer- 
kesszük be őket. Az Isbcc ilyen módon többnyire teljesen 
átlátszóan tud működni. 


Az LSB fejlesztési környezet használata 

Az LSB fejlesztési környezett csomagjainak telepítése után 
a példaalkalmazás átültetése (porting) a szokásos három lé- 
péses műveletre egyszerűsödik, egy apró különbséggel: 


cc-Isbcc ./configure 
make 
make install 


(Mivel nem minden .configure figyeli a CC környezeti változót, 
érdemes elolvasni a help-jét, miképpen adhatjuk meg neki 
az lsbcc-t (pl: ./configure -cc-1sbcc) — a ford.) 


A configure parancsfájl az Isbcc-t használja a GCC helyett, 
és ezzel le is vezényli a az LSB környezet különféle teszt- 
jeit, ráadásul beállítja aprogramhoz szükséges módosítá- 
sokat és korlátozásokat. Általánosságban a teljes funkcio- 
nalitás közel azonos lesz azzal mintha GCC-t használ- 
tunk volna. Gyakorlatképpen próbáljuk meg lefuttatni 

a configure parancsfájlt mindkét módon és hasonlítsuk 
össze a kapott eredményt. Azzal, hogy a configure pa- 
rancsot az Isbcc használatára utasítottuk, egy másik 
előnyhöz is jutunk: a létrehozott make fájlokban a CC vál- 
tozó automatikusan az Isbcc lesz, nem kell tehát figyel- 
nünk, hogy minden egyes make futásakor megadtuk-e 
(make cc-1sbcc). 

Az 1sbcc parancs alapértelmezés szerint a GCC-t hívja meg 
a módosított paraméterekkel, de környezeti változóban 
megadhatunk neki más használandó fordítóprogramot is. 
Bármilyen fordítóval tud dolgozni, a feltétel, hogy parancs- 
sori kapcsolói sszeférjenek a GCC kapcsolóival. 


Teszteszköz 

Az alkalmazás elkészítése után az Isbappchk programmal 
próbálhatjuk ki, hogy valóban megfelel-e az LSB elvárásai- 
nak. A program ellenőrzi az alkalmazásban felhasznált 
megosztott könyvtárak listáját, továbbá megvizsgálja, való- 
ban csak az LSB által jóváhagyott 

csatolófelületeket használjuk-e. Nézzünk egy példát a hasz- 
nálatára: 


ft /opt/lsbappchk/bin/lsbappchk /bin/1s 


/opt/Isbappchk/bin/Isbappchk for LSB Specification 
see 38 
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checking binary /bin/ls 

Incorrect program interpreter: /1lib/ld-Tinux.so.2 
Header[ 1] PT INTERP Failed 

Found wrong interpreter in .interp section: 

5 /1ib/ld-Tinux.so.2 instead of: /Tib/ld-1Isb.so.1 
DT. NEEDED: librt.so.1 is used, but not part 

ssof the LSB 

Symbol clock gettime used, but not part 

s of LSB 


Az LSB nem követeli meg, hogy az operációs rendszer által 
nyújtott eszközök maguk is megfeleljenek az LSB követel- 
ményeinek. Ezért nem is igazán várjuk el, hogy a terjesztés 
saját /bin/1s programja átmenjen ezen a teszten. Egysze- 
rűen csak kézenfekvő példa volt. 

Az 1Isbappchk kimenetéből megtudhattuk, hogy az 
/bin/1s nem felel meg az LSB elvárásoknak. Az első 
probléma, hogy nem az LSB által megadott parancsértel- 
mezővel, azaz a /1ib/1d-1sb. so. 1-el fordították le. 

A következő gond, hogy az alkalmazás a librt.so.1 könyv- 
tárat igényli, amely nem része LSB által meghatározott 
könyvtárkészletnek. Végül pedig, hogy felhasználja 

a clock gettimeO függvényt, de nem statikusan szer- 
kesztettük az alkalmazásba (a librt.so.1 könyvtárban 
találnánk meg egyébként). 

Az ilyen alkalmazások javítása általában úgy történik, hogy 
újrafordítjuk az Isbcc segítségével, amely helyesen állítaná 
be a parancsértelmezőt és a librt.a könytárat használná 

a librt.so helyett. Néha, a statikusan beszerkesztett könyv- 
tár miatt újabb nem-LSB szimbólumok kerülnek az alkal- 
mazásunkba, így aztán az egész folyamatot többször meg 
kell ismételnünk. 

Néhány nagyobb alkalmazás vagy egymáshoz szorosan 
kapcsolódó alkalmazáscsoport esetében kívánatos lehet 
olyan megosztott könyvtárak létrehozása, amelyet csak 
ezek az alkalmazások használnak. Ez LSB alatt is engedé- 
lyezett feltéve, hogy a megosztott könyvtár az alkalmazás 
részeként települ valamint az alkalmazás saját adatterületén 
és nem a rendszer-programkönyvtár mappák valamelyik- 
ében található. Az Isbappchk -L kapcsolója segítségével 

a teszteszköznek megadhatjuk azon megosztott könyvtárak 
az alkalmazás részének tekintünk. Nézzünk meg például az 
LSB szerint fordított Apache Web kiszolgálót, amely három 
saját megosztott könyvtárat használ: 


ft /opt/lsbappchk/bin/lsbappchk 
5-L /opt/1sb-apache/jlib/libaprutil.so.0 
5-L /opt/1lsb-apache/lib/libexpat.so.0 
5-L /opt/1lsb-apache/lib/Tibapr.so.0 
5 /opt/1sb-apache/sbin/httpd 
/opt/1Isbappchk/bin/1sbappchk for LSB 
sSpecification 1.3.3 
Adding symbols for library /opt/ 
5 1sb-apache/lTib/Tibaprutil.so.0 
Adding symbols for library /opt/ 
5 1sb-apache/lib/libexpat.so.0 
Adding symbols for library /opt/ 
5 1sb-apache/lTib/libapr.so.0 
checking binary /opt/1sb-apache/sbin/httpd 








Csomagolás 

Amint azt korábban említettem, az LSB kimondja, hogy 

a csomagnak az RPM fájlformátumot kell használnia. Ez 
nem jelenti azt, hogy az alkalmazásunk csomagját az RPM 
programmal kell elkészítenünk, bár általában valóban ez 

a legpraktikusabb megoldás, főleg akkor, ha már egyébként 
is használjuk. Másik lehetőség lehet például, hogy a csoma- 
got Debian formátumban készítjük el, majd az alien segít- 
ségével alakítjuk RPM csomaggá. Akár más eszközöket is 
használhatunk az RPM formátumú csomag létrehozásához. 
Van ugyan egy kezdetleges mkpkg nevű programunk az 
RPM fájlformátum készítéséhez, de minden valószínűség 
szerint a legelszántabb hackereken kívül más számára csak 
valamilyen segédprogramon keresztül használható. 
Alkalmazáskészletünkben most elkészítjük az alkalmazást, 
majd egy ideiglenes root könyvtárba telepítve meghívjuk 
az RPM-t a csomag összecsomagolásához és telepítéséhez. 
Kicsit nehézkesnek tűnhet ugyan, de viszonylag probléma 
mentesen működik és valamivel egyöntetűbb eredményt 


biztosít a vadonban fellelhető különféle RPM változatoknál. 


Nézzük meg, hogy néz ki az xpaint alkalmazás példa defi- 
níciós állománya: 


Summary: An X Window System paint program 
Summary: XPaint 

Name: 1sb-xpaint 

Version: 2.6.2 

Release: 3 

Vendor: Free Standards Group 

License: MIT 

Group: Appbat/graphics 

Buildroot: /usr/src/appbat/pkgroot/1sb-xpaint 
AutoRegProv: no 

PreReg: lsb 5— 1.3 


Jdescription 

LSB szabványnak megfelelő xpaint verzió. 
Az XPaint X Window System alapú, színes 
képszerkesztő program. 

Az Xpaint elsősorban a célból került az LSB 
Alkalmazás készletbe, hogy rajta keresztül 
bemutathassuk az X11 könyvtárak 
használatát. 

Jpre 

Jjinstall 

Jpost 

J6preun 

Jppostun 

J7clean 


files 


jattr ( - bin bin ) /opt/1sb-xpaint 
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Ezen és az alkalmazáskészletben megtalálható alkalmazá- 
sok fordításához és csomagolásához használt forráskódot az 
LSB projekt CVS fájában találjuk meg. 


És ez tényleg működik? 

Igen, tényleg működik, bár az igazat megvallva, időn- 
ként még mindig beleszaladunk néhány alkalmazásba 
amelyek nem mindig követik a tiszta, hordozható kód 
szabályait. A LSB ellenőrző készlet részeként létrehoztuk 
egy, az itt leírt eszközökkel lefordított alkalmazás- soro- 
zatot. Eme alkalmazások közt megtaláljuk az Apache, 
Samba, Lynx, Python, xpdf és groff programokat. Meg- 
próbáltunk olyan valódi alkalmazásokat összeválogatni 
amelyek a lehető legnagyobb területet lefedik az LSB 
csatolófelület készletéből. 


Mi a helyzet a C-t -- alkalmazásokkal? 

Az LSB 1.3 nem támogatja a C-4-- nyelvet, így a szükséges 
könyvtár statikus beszerkesztésének szabálya lép érvénybe. 
Ennek elkerülésére az LSB 2.0 változatába már beépítettük 
a C4-4 támogatást. Közreadjuk az Isbdev-c-- 4 csomagot, 
amely tartalmazza a Isbcc segítségével beállított és lefordí- 
tott libstdc-- 4- könyvtárat. Ezzel és a GCC 3.2 változatával 
úgy tűnik jó eredményeket lehet elérni. Más fordítókat 

és különféle C és C--- könyvtárakat is kipróbáltunk, de 

az alkalmazás jellegétől függően különféle problémákba 
ütköztünk. 


Célok és elképzelések 

Az LSB fejlesztésénél általános szinten további könyvtára- 
kat fogunk felvenni a specifikációba, feltéve, hogy közmeg- 
egyezés alakul ki szükségességük tekintetében és elértek 
egy adott stabilitási szintet. Ezáltal eltüntethetjük a terjesz- 
tés által kiadott és az LSB-nek megfelelő alkalmazások ké- 
szítése közötti rést. 

Az LSB fejlesztői környezet esetében tovább javítjuk majd 
az eszközök használhatóságát és átlátszóságát. A fejlesztői 
környezet karbantartása igen aktív, és az eszközöket hasz- 
nálók visszajelzéseit nagyra értékeljük. Az LSB 2.0 változat- 
ban megjelenő C-t -- segítségével, a fejlesztési környezet le- 
cserélheti a manapság használt Isbdev-c-t -- csomagot 

a C4--4 stub könyvtárra, amely így az alap LSB fejlesztői 
csomagba vándorol. 

Jelenleg jó néhány kapcsolót be kell állítanunk az rpmrc 
vagy az rpmmacros állományban ha az RPM-et LSB szab- 
ványú csomagok előállítására szeretnénk rábírni. Remél- 
jük idővel elő tudunk majd állítani egy LSB módot az 
rpmbuild programhoz, amely mindezt automatikusan 
megoldaná. 


Linux Journal 2004. május, 121. szám 


Stuart R. Anderson elkövette azt a hibát, hogy 
meghallották amikor kijelentett, hogy , tudom 
hogyan kellene ezt megoldani", és így azóta 
az LSB Written Specification vezetője lett. 

7: Amikor nem az LSB-n dolgozik, Stuart szor- 
e . gosan ügyködik Dél Carolina felvilágosításán 
a nyílt forrású témákban, egyesével térítve meg a cégeket. 
Az andersondfreestandards.org címen érhető el. 
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Az egyik legrégebbi és legtöbb szolgáltatást nyújtó webközösség-rendszer 
egyben az egyik legnehezebben telepíthető is. Reuven ezúttal mod perl-lel és 
egyéb előfeltételekkel kapcsolatos tanácsokkal segít Slash webmesterré válni. 


webnapló, vagy más néven blog népszerűsége 
A néhány éve megállíthatatlanul nő, és semmi jele 

annak, hogy kicsit is alábbhagyna. Noha sok web- 
napló-író továbbra is független szolgáltatások — például 
a LiveJournal vagy a Blogger — segítségével jegyzi le gondo- 
latait, egyre könnyebbé válik saját kiszolgálón webnaplót 
működtetni. Az elmúlt néhány hónapban számos program- 
csomagot megnéztünk, amelyek biztosítják ezt a lehetőséget. 
Ezek közé tartozik a COREBlog, amely egy Zope termék, és 
a Blosxom, egy Perl-ben íródott CGI programcsoport. 
A múlt hónapban, amikor a XOOPS-ot vizsgáltuk, egy kicsit 
másmilyen weblog-rendszert láttunk. A XOOPS, akárcsak 
az unokatestvérei, a PHPNuke és a PostNuke, a csoportok 
és tagok felügyelete mellett lehetővé teszi a felhasználók- 
nak tartalom-kezelés és online közösség létrehozását is. 
A XOOPS segítségével egyszerűen lehet a rendszer minden 
felhasználójának saját, egyéni webnaplót biztosítani. 
Bármennyire is népszerű a XOOPS, a közösségi programok 
ősatyja vitathatatlanul a Slash, amely a közkedvelt 
5 httoNwwwi.slashdot.org és a 5 httoMXwww.use.perl.org 
webhelyek motorja. A Slash elsősorban hírek és hozzászólá- 
sok közzétételére szolgál, de nagyon hatékony webnapló 
szolgáltatása is van, amely a rendszer minden felhasználója 
számára elérhető. Néhányan erre azt mondanák, hogy 
a Slashdot maga egy közösség által szerkesztett webnapló, 
és ez a nézet számomra is egész meggyőző. A legjobb az, 
hogy ez a webnapló szolgáltatás együttműködik az oldal 
többi elemével, így ha egy másik felhasználótól különösen 
éles elméjű vagy ízléstelen hozzászólást olvasunk, rögtön 
megnézhetjük a naplóját, hogy többet tudhassunk meg róla. 
Ebben a hónapban egy egyszerű Slash webhely telepítését 
és beállítását nézzük meg, amely beépített támogatást bizto- 
sít a felhasználóknak és a webnaplóknak (vagy ahogy 
a Slash-zsargon mondja: ,journal"-nak). A következő hó- 
napban közelebbről tanulmányozzuk a Slash webnapló 
lehetőségét, valamint azt, hogyan lehet beállítani és változ- 
tatni, hogy megfeleljen egyedi igényeinknek. 


Háttér 

A Slash terjesztésének és megvitatásának a fő helye 

a Slashcode. A cikk keletkezésekor, 2004. áprilisának elején, 
a legutolsó hozzászólás címe: , Barátságos Slash telepítés", 
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amelyben a szerző azt kérdezi, létezik-e a Slash telepítésé- 
nek világos, egyszerű módja. Sajnos, úgy tűnik, a válasz 
nem - és ennek számos oka van: 


e  AdSlash leírása és használati utasítása az emberek több- 
ségét a hivatalosan kiadott .tar.gz csomagokhoz vezeti, 
amelyek több, mint két éve elavultak. 

e A legújabb CVS (Concurrent Versions System) változat 
szabadon hozzáférhető és naprakész, de nem kizárt, 
hogy megbízhatatlan, hacsak nem tudjuk, melyik cím- 
kézett változatot kell letölteni. 

e A telepítés nagyrészt manuális művelet, számos kritikus 
ponton hibalehetőségekkel. 

e A Slash leírása nem túl jó minőségű. 

e Ha sikerülis a kód egy friss, működő példányát telepí- 
teni, a teljes Slash telepítéshez szükség van a mod perl, 
a Template Toolkit, a MySOL telepítésére, egy csomó 
más Perl modulra és független eszközre, a saját, kissé 
eltérő és nem szabványos beállításaikkal. 


Ha járatosak vagyunk a mod perl-ben, a MySOL-bern, és az 
Apache-ban, akkor a Slash telepítése egy kissé kellemetlen, 
de elvégezhető folyamat. Ha kevésbé vagyunk gyakorlot- 
tak, az eredmény valószínűleg megéri a fáradságot, számít- 
sunk rá, hogy menet közben nagyon sokat megtanulunk 
ezekről az alkalmazásokról. Lehet azonban, hogy egyszer 
csak azon kapjuk magunkat, hogy az IRC csatornán, vagy 
a webhelyen keresünk tanácsokat és ötleteket. 

A Slash telepítésének első lépése az Apache, a mod perl és 

a MySOL telepítése. A MySOL bármelyik újabb változata 
megfelelő, az igazi gond az Apache-csal és a MySOL-lel lehet, 
amelyeket elsőre talán bonyolult telepíteni. Szerencsére, az 
évek során a telepítés folyamatának ez a része alapvetően 
nem változott, ami azt jelenti, hogy követhetjük az 
InstallSlash oldalon található MySOL, Apache és mod perl te- 
lepítési utasításokat. (Lásd az online források részt). Ha sem 

a Perl, sem az expat nincs telepítve a rendszeren, akkor ehhez 
is segítséget nyújtanak az InstallSlash utasításai. Ne feledjük, 
hogy RedHat és Fedora rendszereken nem csak az expat 
RPM-et, hanem az expat-devel RPM-et is telepíteni kell. Meg 
kell adnunk egy MySOL adatbázist is, amelyben a hely adatai 
tárolódnak, alaphelyzetben ez a slashdb nevet kapja. Az 








Apache és a mod perl fordításakor az EVERYTHING-1 megadá- 
sának szükségessége jelentős problémaforrás. Ez működésbe 
hozza a mod perl összes horgát (hook), ezzel lehetővé teszi 

a mod perl számára, hogy felülbírálja az Apache minden 
alapértelmezésbeli működését, beleértve a hitelesítést, az en- 
gedélyezést, az URL átírást és a naplózást. AZ EVERYTHING-1 
megadása nélkül a mod perl csak tartalmat hozhat létre. Ha 

a rendszerünket már telepített mod perl-lel szereztük, valószí- 
nűleg az EVERYTHING-1 megadása nélkül fordították, ami azt 
jelenti, hogy magunknak kell újrafordítanunk. 

A Slash használati utasítás a PERL MARK WHERE-1 beállítá- 
sát is javasolja a rendszergazdáknak fordításkor, habár 

a mod perl kódja és leírása szerint ez az utasítás törli a meg- 
határozatlan értékekre vonatkozó figyelmeztetések nagy ré- 
szét a hibanaplóból. Én figyelmen kívül hagytam ezt a taná- 
csot, és a Slash-t a létező mod perl telepítésemen használ- 
tam, de nem tapasztaltam semmilyen káros hatást. 
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Ha úgy döntünk, hogy biztonsági okokból, vagy egyéni 
ízlésünk miatt megváltoztatjuk az értékeket, semmiképp 
ne felejtsük el, milyen neveket használtunk. 

A Bundle::Slash letöltésének legnehezebb része a Template 
Toolkit telepítése. A Template Toolkit egy népszerű és haté- 
kony sablon-rendszer a mod perl alatt, ami arra szolgál, 
hogy egy Slash webhely különböző oldalait következetes 
és praktikus módon jelenítse meg. 


Címkézett változatok letöltése a CVS-ről 

Ennél a pontnál magát a Slash kódot kell letöltenünk és 
telepítenünk. Az InstallSlash használati utasítás végigkísér 
minket a SourceForge-on található, legfrissebb csomagolt 
változat (2.2.6) letöltésének és telepítésének folyamatán. 
Viszont, mint fentebb említettem, 2.2.6 kibocsátása óta eltelt 
két évben rengeteg fejlesztés történt, és ezek a javítások 
csak a CVS változatban elérhetőek. 
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1. ábra Ide írjuk a szöveget... 


Végül, telepítsük a rendszerre a CPAN-ról (olyan ki- 
szolgálók világméretű hálózata, amelyek szabadon fel- 
használható Perl modulokat és leírásokat tartalmaznak) 
a Bundle::Slash csomagot, az önműködő CPAN eszkö- 
zök segítségével. A Bundle::Slash tulajdonképpen sem- 
milyen kódot nem tartalmaz, csak felsorolja a Slash fut- 
tatásához szükséges modulokat, így nekünk nem kell 
megjegyezni (és begépelni) az összes telepítendő Slash- 
hez kapcsolódó modult. Rendszergazdaként bejelent- 
kezve a következő sor begépelésével telepíthetjük 

a modulokat: 

f perl -MCPAN -e "install Bundle::Slashi 

Ha még ezelőtt sosem használtuk a CPAN-t, meg kell ad- 
nunk néhány CPAN-nel kapcsolatos paramétert, köztük 

a legközelebbi CPAN archívumot, amelyről modulokat tölt- 
hetünk le. Ez lehet, hogy elsőre egy kicsit bonyolult lesz, 
bár elfogadhatjuk az alapértékeket is, valószínűleg minden 
következmény nélkül. 

A CPAN modulok telepítésének egyik nehézsége 

a DBIXx::Password, amely a telepítésekor a webhelyre vonat- 
kozó információkat kér. Az InstallSlash utasításai meg- 
mondják, mit kell válaszként beírni a parancssorba. 
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2. ábra 


...és Így jelenik meg. 


A következő paranccsal letölthetjük a legfrissebb változatot 
a CVS-ről, és elmenthetjük egy slash nevű könyvtárban. 


cvs -Z3 -d:pserver:anonymousűcvs . sourceforge.net: 
5 /cvsroot/slashcode co -r T 2 3 0 148 slash 


Ugyanakkor a legfrissebb CVS változat SourceForge-ról 
való letöltésének megvannak a maga buktatói, mert ez- 
Zel vállaljuk a kockázatot, hogy olyan kódot telepítünk, 
amit mostanában töltöttek fel, de nem ellenőriztek. A leg- 
jobb megoldás a címkézett változat használata. Ahogy 

a tapasztalt CVS fejlesztők tudják, minden CVS állomány- 
nak van egy változatszáma (revision number), mint példá- 
ul 1.5, vagy 2.8 vagy 3.1.1.2. Ezek a változatszámok csak 
az egyes állományok változataira vonatkoznak, és semmi 
közük a teljes projekthez. Ezért annak ellenére, hogy 
program projekt 2.0-s változatként kerül a nyilvánosság 
elé, az egyes állományok majdnem biztos, hogy nem 
2.0-s változatszámúak. Hogy egy közös nevet (vagy szá- 
mot) lehessen rendelni a projekt összes állományának 

a pillanatnyi állapotához, címkéket, vagy más néven jel- 
képes változatokat kell használni. Amennyiben van írási 
jogunk, megcímkézhetjük a jelenlegi release-2-0 könyv- 
tárat, a következőképpen: 
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cvs tag release-2-0 


A címkék nem tartalmazhatnak bizonyos karaktereket, pél- 
dául vesszőt vagy pontot sem. Ezért kell kötőjelet használni 
pont helyett annak jelzésére, hogy a programunk 2.0-s ki- 
adású. Ez felveti azt a kérdést, hogy melyik címkét tudjuk 
vagy szükséges letölteni. A Slash esetében a kód lassan ha- 
lad a 2.3.0-s változat felé, és a fejlesztők egységesítették 

a címkéket, a következőképpen: T 2 3 0 XXX. A T azt jelö- 
li, hogy tesztelt, és az XXX minden egyes címkével növek- 
szik. A cikk írásáig a legfrissebb címkea T 2 3 0 148, me- 
lyet a következőképpen tölthetünk le: 


cvs -Zz3 -d:pserver:anonymousűcvs . sourceforge.net: 
5 /cvsroot/slashcode co -r T 2 3 0 148 slash 


Ez a parancs létrehoz egy slash nevű könyvtárat, és minden 
Slash-hez kapcsolódó kódot, könyvtárat és leírást ebbe tesz. 
Az INSTALL állomány, amely azoknak az utasításoknak 

a naprakész változata, amelyeket arra terveztek, hogy az 
éppen letöltött CVS változattal működjenek, különösen 
hasznos. Követtem a fájlban leírt utasításokat, begépeltem 
a make instal1 parancsot az összes Slash alkotóelem telepí- 
téséhez. A telepítési folyamat során kapott üzenet megmu- 
tatja, milyen parancsot tegyünk az Apache beállító fájl vé- 
gére. Ez biztosítja, hogy az Apache tartalmazza a megfelelő 
Perl modulokat az induláskor, ezzel lényegesen csökkentve 
a mod perl memóriaigényét és futási idejét. 

Az egyik jó dolog a Slash-ben, hogy könnyedén tud több 
webhelyet kezelni ugyanazzal a kóddal. Azaz, ha úgy 
döntünk, hogy külön online közösséget szeretnénk 

a Perl, a Python, a Tcl és a Ruby számára, akkor a Slash 
ezt képes kezelni. Minden közösségnek saját gépnévre 
van szüksége, de ezek lehetnek egymástól teljesen külön- 
bözőek. Más szóval, egy Slash weboldal telepítése a Slash 
program telepítésétől különálló folyamat. Amikor a prog- 
ramot már telepítettük, alaphelyzetben a /usr/local/slash 
alá, a következő parancs futtatásával hozhatjuk létre az 

új webhelyet: 


/usr/local/slash/bin/instal1-slashsiíte -u USER 


Itt a USER ugyanaz a virtuális felhasználó, amelyet 

még a DBIx::Password telepítésekor hoztunk létre, alap- 
helyzetben a virtslash nevet kapja. Az instal1-slashsite 
még néhány kérdést feltesz, többek közt a rendszergazda 
felhasználónevét és jelszavát, ezután az Apache apachect1 
programmal való leállítására és elindítására utasít. Ez 

a program általában a /usr/local/apache/sbin alá van tele- 
pítve. Az apachect1 program restart utasítását nem sza- 
bad használni, különösen, amikor mod perl-lel dolgozunk. 
Le kell állítani az Apache-ot, várni néhány másodpercet, 
hogy a folyamatok teljesen ki tudjanak lépni, és azután 
újraindítani. 

Amikor megpróbáltam futtatni az install-slashsite-ot, 
észrevettem, hogy legalább egy CPAN modul hiányzik 
(LWP::Parallel::LIserAgent). Nem tartott sokáig telepí- 

teni, de csalódott voltam, amikor kiderült, hogy sem 

a Bundle::Slash, sem a make install nem észlelte 

vagy javította ezt. 
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Egy egyszerű Slash weboldal 

A Slash webhely most már használatra kész. Az én gé- 
pemen, amelynek a saját otthoni hálózatomon chaim- 
weizmann a neve, meg tudtam nézni a webhelyemet úgy, 
hogy a Http://chaim-weizmann címre ugrottam. 

Egy újonnan telepített Slash weboldal természetesen nem 
valami izgalmas. Ha azzal a rendszergazda felhasználónév- 
vel és jelszóval lépünk be, amit az instal1-slashsite-nek 
adtunk meg, számos lehetőséget és menüt kapunk, amely 
elég nagy irányítást biztosít a rendszer fölött. Sok menüt 
nehéz megtalálni, és igénybe vesz némi időt, mire a Slash 
rendszergazda rájön, hogy hol hajtódnak végre a különbö- 
ző változtatások, a webhelyen, vagy a lemezen lévő sablo- 
nokban és programokban. A slashguide.pod, amely a CVS 
változattal kapott docs könyvtárban található, jó bevezető 
a Slash webhelyek karbantartásába. 

Ha már valamennyire ismerjük az eredeti Slashdot 
webhelyet, rögtön elkezdhetünk történeteket feltenni, és 
gyűjteni a hozzászólásokat. A webhely rendszergazdája- 
ként bejelentkezve kattintsunk a főoldal tetején a New (Új) 
hivatkozásra. Adjunk meg egy témát, egy címet, egy kate- 
góriát, egy bemutató változatot (a főoldalon látható majd) 
és egy hosszabb változatot (az önálló történet-oldalon lát- 
ható majd). Még közvélemény-kutatást is csinálhatunk, 
vagy összekapcsolhatunk egy történetet egy meglévő köz- 
vélemény-kutatással. Mikor jóváhagytuk a történetet, az 
egész világ számára láthatóvá válik. Az oldal felhasználói- 
nak tetszés szerint lehetővé tehetjük a hozzászólást, sőt, 
még moderátorok is lehetnek. A Slash történetek közösségi 
moderálása és meta-moderálása tényleg a legizgalmasabb 
ötlet, amit a Slash letett az asztalra. 


Következtetés 

A Slash-t nehezebb telepíteni, mint bármely program- 
csomagot, amelyről eddig szó volt. Ez részben azon 
múlik, hogy a szerzők milyen megoldást választottak, 
mivel a mod perl-t lényegesen nehezebb telepíteni, 

mint a XOOPS és a Zope által használt PHP-t. Ugyan- 
akkor, a Slash több közösségi és webnapló lehetőséget 
kínál, mint más programcsomagok, közismerten nagy 
forgalmat képes kezelni, és igen magas szinten lehet 
karban tartani. 

Ha nem félünk, hogy összepiszkoljuk a kezünket, és szeret- 
nénk elérni azt a hatékonyságot, amit a Slashdot webhely 
biztosít, a Slash jó választás lehet a közösségek vagy egyé- 
nek által vezetett  webnaplók számára. Következő hónap- 
ban olyan személyes naplókat nézünk meg, amelyeket 

a Slash segítségével lehet létrehozni egy olyan társrendszer- 
rel együtt, amelynek segítségével csoportosítani lehet a fel- 
használókat a rendszerben, olyan virtuális közösséget létre- 
hozva, amely a valódi világot tükrözi. 
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Rewven M. Lerner (5 http:/Avww.lerner.co.il/atf) 
Nyílt forrású programokra, valamint web- és adat- 
bázis-alkalmazásokra szakosodott tanácsadó. 
Könyve, a Core Perl, 2002 januárjában jelent meg 
a Prentice Hall gondozásában. Reuven feleségével 
és lányaival nemrég költözött Chicagóba. 
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Elemi adatkapcsolati protokollok. 


lokkal foglalkozunk, azaz megnézzük, miként zajlik 

az adatkapcsolati rétegen , belüli" kommunikáció. 
Eddig sok érdekes dolgot hallhattunk az adatkapcsolati 
réteg feladatairól, most itt az ideje, hogy ezek gyakorlati 
megvalósításáról is szót ejtsünk. Adott tehát a probléma: 
A és B gép adatot cserélnének egymással. Mindezt egy 
olyan világban szeretnék megtenri, ahol a keretek el- 
tünhetnek, megsérülhetnek, illetve a két gép sebessége 
között jelentős eltérés is előfordulhat. Hogy mindez ne 
jelenthessen problémát, szükség lesz az adatkapcsolati 
protokollokra. 
Továbbra is az egyszerűből haladunk a bonyolultabb felé, 
azaz először egy olyan protokollal ismerkedünk meg, ahol 
csak az A gépnek van módja adatot küldeni a B felé, és 
élünk azzal a nevetséges feltételezéssel, hogy az A gép 
végtelen mennyiségű elküldendő adattal rendelkezik, 
illetve az adatok előállítása semennyi időbe se kerül. 
(A hálózati réteg mindig készenlétben áll). A későbbiekben 
megszabadulunk ezektől a megkötésektől, ezzel eljutva 
egy gyakorlatban is használható protokollhoz. 


S orozatunk jelen részében az adatkapcsolati protokol- 


Keretek és csomagok 

Ahhoz, hogy bemutathassuk az adatkapcsolati protokollok 
működését, fontos, hogy bizonyos dolgokban előre megál- 
lapodjunk. Most sem térünk el az általunk bemutatott háló- 
zati modelltől, azaz a fizikai, az adatkapcsolati és a hálózati 
réteget továbbra is független, egymással párhuzamosan fu- 
tó folyamatokként tételezzük. Minden réteg csak a , saját 
megfelelőjével" kommunikál, azaz az A gép hálózati rétege 
a B gép hálózati rétegével cserél információt. Emlékezzünk 
csak az első részben bemutatott filozófusok esetére: mind- 
két filozófus egymással kommunikál, de az üzenetváltást 

a titkárnők valósítják meg. 

Ebben az esetben a hálózati réteg a filozófus, az adatkap- 
csolati réteg a titkárnő, a fizikai réteg pedig az email vagy 
fax, amin a titkárnők az üzeneteket továbbítják. A valóság- 
ban ezek a rétegek nem minden esetben vannak ennyire 
különválasztva. Az adatkapcsolati réteg lehet például 

a hardver része is. Ehhez a modellhez mi csak azért ragasz- 
kodunk foggal-körömmel, mert így a különböző részfel- 
adatok gyakorlati megvalósítását egymástól függetlenül 

is be tudjuk mutatni. Sőt mi több: egyik rétegnek sem kell 
tudnia arról, hogy a másik miként oldja meg a saját felada- 
tát. Ugyanígy a filozófusokat sem foglalkoztatják az élet 
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értelméhez képest olyan, teljesen jelentéktelen kérdések, 
hogy például a titkárnőjük email-en vagy faxon továbbítja 
az üzeneteiket. 

Mostantól kezdve a hálózati réteg által egyszerre elküldött 
adatblokkot csomagnak nevezzük, az adatkapcsolati réteg 
megfelelője" pedig a keret lesz. Ha a hálózati réteg adatot 
kíván küldeni, akkor ő azt először egy csomagba szervezi 
(hogy egy csomagnak milyen részei vannak, arról majd 
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a hálózati réteg tárgyalásakor visszatérünk), ezt követően 
pedig átadja azt az adatkapcsolati rétegnek. Fontos, hogy 
míg a hálózati réteg számára a csomag egy jól meghatáro- 
zott struktúrával bír, az adatkapcsolati rétegnek ez csak 
bitek sorozata. 

Az adatkapcsolati réteg a csomaghoz hozzáragaszt némi 
plusz információt, ezeket a keret fejlécének fogjuk nevezni. 
A keret tehát két részből áll: a hálózati réteg számára is ér- 
dekes adatmezőből, és a fejlécből, amely további három me- 
zőre oszlik. 

Az első a kind, amely egy logikai érték, és azt mondja meg, 
hogy van-e adat a keretben. Erre nem azért van szükség, 
hogy haszontalan üres keretekkel terhelhessük kedvünkre 
a hálózatot, hanem azért, hogy lehetőség legyen vezérlőke- 
retek küldésére is. Amikor ugyanis érkezik a keret, akkor 
annak adatmezejét az adatkapcsolati réteg mechanikusan 
továbbítja. Felmerülhet azonban az igény, hogy a két adat- 
kapcsolati réteg kommunikálhasson egymással. 

A keret fejlécéhez tartoznak még az ack és a seg mezők, 
ezekkel valósíthatjuk meg a keretek sorszámozását, illetve 
a nyugtázást. 

Mivel az algoritmusokat a legegyszerűbben valamilyen 
programnyelvhez hasonló nyelven segítségével lehet ismer- 
tetni, mi egy C-hez nagyon hasonló, ám rendkívül magas 
szintű nyelvet használunk a protokollok bemutatására. 


Korlátozás nélküli szimplex protokoll 

Ez a lehető legegyszerűbb protokoll, amit csak el tudtunk 
képzelni. Mint már említettük, először azt a helyzetet vizs- 
gáljuk, amikor csak az 

A gép küld, akinek mindig van adata, és egy percet sem 
kell várni egy-egy keret előállítására. A vevő sincs híján 

a mesébe illő tulajdonságoknak: végtelen gyorsan képes 
feldolgozni a hálózaton hozzá érkező kereteket. 

Ezt úgyis megfogalmazhatjuk, hogy a vevő végtelen 
puffer területtel rendelkezik, ahova bármennyi feldolgo- 
zZásra váró keret befér. 
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Azon már meg se lepődjünk, hogy a kommunikcáiós csator- 
na annyira jó minőségű, hogy minden keret sértetlenül 
megérkezik. 

A 2. listán láthatjuk ennek a protokollnak egy megvalósítá- 
sát. A kuldoO függvény a küldő, a vevoO pedig a fogadó 
gépen fut. Mindkét eljárás lelke egy végtelen ciklus. A kül- 
dő amilyen gyorsan csak tudja, fogadja az adatokat a háló- 
zati rétegtől, és egyből be is rakja egy keret info mezejébe. 
A keret egy összetett típus, ennek definiálását láthatjuk az 
1. listán. Ez a protokoll csak az info mezőt használja, hiszen 
forgalomszabályozásról, illetve nyugtázásról ő még semmit 
sem hallott. 

A küldő miután összerakta a keretet (ami most még nem 
volt egy különösebben megterhelő feladat), egyből át is 
dobja a fizikai rétegnek, amely bitenként továbbítja azt 

a csatornán keresztül. 

A vevő eljárás sem bonyolultabb ennél. Először is vár, hogy 
történjen valami. Jelen esetben a jövő varázsgömb nélkül 

is kiszámítható, ugyanis csak egy dolog történhet: egy sér- 
tetlen keret érkezik. Az , e" változó értéke tehát biztosan 
keret erkezett" lesz, így annak értékének ellenőrzése nél- 
kül egyszerűen csak át kell venni a keretet a fizikai rétegtől, 
majd továbbítani annak info mezőjét a hálózati réteg felé. 


Szimplex , megáll és vár" protokoll 

A számítógépeink továbbra is varázskábellel vannak össze- 
kötve, ahol nem sérülhetnek, illetve veszhetnek el a kere- 
tek. A vevő azonban már nem végtelen memóriájú, így 
előbb vagy utóbb a folyamatosan érkező keretektől megte- 
lik a puffer, és kénytelen lesz a forrásállomáshoz szünetért 
könyörögni. 

A megoldandó probléma tulajdonképpen nem más, mint 
hogy valamilyen módszerrel visszafogni a küldő állomást 
abban, hogy keretek sokaságát zúdítsa a vevőre. Általáno- 
san úgy lehetne ezt megfogalmazni, hogy ha mondjuk 

a vevőnek T időbe telik, míg a fizikai rétegtől a hálózati ré- 
tegig eljuttatja az adatot (azaz T a FizikaiRetegtol és 

a HalozatiRetegnek utasítások végrehajtásának ideje), ak- 
kor a küldő T idő alatt átlagosan kevesebb mint egy keretet 
küldhessen. 

Erre a legkézenfekvőbb megoldás az lehet, ha a forrásba 
,bedrótozunk" valamiféle késleltetést. A vevőnek azonban 
nem csak a keretek fogadásával kell foglalkoznia, hanem 
sok más egyéb feladata is lehet, például más gépekkel is 
kommunikálhat. 

Így a T értéke folyamatosan változhat. Persze előfordulhat, 
hogy létezik a T-re egyfajta legrosszabb érték, amelynél a T 
értéke sohasem lehet nagyobb. Ha ezt választjuk 

a késleltetés időtartamának, akkor biztos, hogy a vevő min- 
den esetben képes lesz feldolgozni az összes keretet, akár- 
mennyi más egyéb teendője is akad. Ezzel azonban az 

a gond, hogy rendkívül pazarló megoldás. Ha ugyanis a ve- 
vőnek éppen nincs semmi dolga, akkor sem fogja gyorsab- 
ban kapni a kereteket. 

Praktikusabb megoldás tehát ha visszacsatolást létesítünk 

a vevő és a forrás között. Ez annyit tesz, hogy a vevőnek 
módjában áll visszaszólni a forrásnak. 

A ,megáll és vár" protokoll esetében például a forrás addig 
nem küldi el a soron következő keretet, amíg a vevő vissza 
nem küld egy ,álkeretet", amellyel közli, hogy az előző ke- 
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1. lista A keret összetett típus 


typedef struct 
T 
bool kind; 
ünt seg, Malek 
csomag info; 
l keret; 


retet sikeresen feldolgozta, készen áll a következő fogadásá- 
ra (3. lista). Az ábrán láthatjuk, hogy tulajdonképpen telje- 
sen mindegy, hogy mi az álkeret, a forrásnak ugyanis csak 
a beérkezés a fontos. Rögtön ezt követően a forrás , feléb- 
red", és ismét elküld egy keretet. Ezután megint várakozik. 
Másik fontos különbség az előző protokollal szemben, hogy 
itt már az adatok visszafelé is áramolnak. Ez azt jelenti, 
hogy az összekötő mágikus kábelnek kétirányúnak kell len- 
nie. Az is igaz, hogy az adatok áramlásának iránya szigorú- 
an változik, azaz hol az egyik, hol a másik küld. 


Ha zaj van a csatornán... 

Bonyolítsuk tovább a helyzetet és cseréljük le a zajmentes 
mágikus hálózati kábeleinket teljesen hétköznapiakra. Az 
előző protokoll nyilván használhatatlan, hiszen most már 
könnyedén előfordulhat, hogy egy-egy keret megsérül, 
esetleg el is veszik. 

A nagy ötlet az, hogy módosítsuk az előző protokollt 

a következőképp: amikor a forrás elküld egy keretet, elindít 
egy időzítőt, és vár, hogy a vevő visszaküldjön egy nyugtát 
a keret sértetlen megérkezéséről. 

Ha az időzítő lejártáig nem érkezik meg a nyugta, akkor 

a kérdéses keret valószínűleg elveszett, ezért a forrás azt is- 
mét elküldi. 

Ez jó megoldásnak tűnik, de végig számításba kell venünk 
azt az esetet is, amikor nem a keret, hanem a nyugta tűnik 
el. Ilyenkor a forrás nem értesül a keret megérkezéséről és 
ismét elküldi azt. 

Ekkor a vevő ismét nyugtáz, és ha nem veszik el ismét 

a nyugta, akkor a forrás küldheti a következőt. Ha kicsit 
utánaszámolunk, láthatjuk, hogy a vevőhöz ugyanaz a ke- 
ret kétszer is megérkezett. Rendkívül kellemetlen, ha pél- 
dául egy állomány átvitelekor annak bizonyos részei meg- 
duplázódnak. 

Ezért a vevőnek valahogy fel kell tudnia ismerni azt, ha 

a beérkezett keret az előző ismétlése. A kereteket legegy- 
szerűbben úgy különböztethetjük meg egymástól, ha sor- 
számmal látjuk el őket. 

A sorszámot nyilván a keret fejlécében tárolnánk, és mivel 
nem jó, ha a fejléc túl nagy, ezért fontos a kérdés: a keretek 
sorszámait hány biten ábrázoljuk? 

Könnyen belátható, hogy erre elegendő egyetlenegy 

darab bit is. Ha végig gondoljuk a protokoll működését, 
akkor megállapíthatjuk, hogy a nem egyértelmű keret csak 
az n. vagy az n-1. lehet. 

Ha ugyanis az n. keret megsérül, akkor nem fog róla 
nyugta érkezni, ezért a forrás addig küldi, amíg végre 
hibátlanul át nem ér. 











2. lista Korlátozás nélküli szimplex protokoll 


Küldő: 
void KuldoO 
í 
keret k; 
csomag cs; 


while(true) // végtelen ciklus 
jú 
HalozatiRetegtol (€cs) ; 
// megkapjuk a hálózati rétegtől az 
// elküldendő csomagot 
KENNTOSZEGSS 
FizikaiRetegnek(8k) ; 


Vevő: 
void VevoO 
í 
keret k; 
esemeny e; 


whileC(true) 
í 
Esemenyrevar (8e); // csak a keret erkezett 
// a lehetséges esemény 
FizikaiRetegtol (£k) ; 
HalozatiRetegnek (ak . info) ; 
3 


Ha a nyugta veszik el, akkor ismét az n. keret kerül elkül- 
désre. Ha a nyugta is rendben megérkezik, akkor kerül 
továbbításra csak az n--1. keret. 

Folytatva a dolgot, ha az n--2. keretet elküldjük, akkor az 
az esemény magában hordozza azt is, hogy az m--1. keret 
nyugtája már sértetlenül megérkezett. Ez pedig azt jelenti, 
hogy az m. keret, és annak nyugtája is célba ért. Ezért 

az egy bites sorszám elegendő. 

Azokat a protokollokat, ahol a forrás minden keret után 

a keret megérkezéséről pozitív visszajelzésre vár, ARO-nak 
(Automatic Repeat reOuest — automatikus ismétléskérés) ne- 
vezik. Ezek is egyirányú (szimplex) protokollok, de már 
tudják kezelni az elveszett kereteket. 

Mi történik azonban akkor, ha a forrás időzítője hamarabb 
jár le, mint ahogy a nyugta célbaérne. Ha már megtörtént 
a keret újraküldése, és az időzítő nullázása, akkor — ha 

a kérdéses nyugta mégis célba ér — a forrás azt fogja gon- 
dolni, hogy ez az imént elküldött keretre érkezett a nyugta. 
Ezért fontos, hogy a forrás valamiképpen tudomást szerez- 
zen arról, hogy a beérkezett nyugta valójában melyik keret 
megérkezését erősíti meg. Persze ezt a problémát könnyen 
orvosolhatjuk azzal, ha maga a nyugta is tartalmazza 

a hozzá tartozó keret sorszámát. A 4. listán láthatunk egy 
példát a zajos csatornán is alkalmazható szimplex megáll- 
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3. lista Szimplex megall es var protokoll 


void KuldoO 
ü 
keret k; 
csomag cs; 
esemeny e; 


while(true) 
ml 
HalozatiRetegtol (€cs) ; 
kin tosztes 
FizikaiRetegnek(8k) ; 
Esemenyrevar (£8e) ; 
// addig ne folytassuk, amig nincs ra 
// engedely 


void Vevol 

ú 
keret k, s; 
esemeny e; 


whileC(true) 
í 
Esemenyrevar (ge); // csak a keret erkezett 
// a lehetséges esemény 
FizikaiRetegtol (£k) ; 
HalozatiRetegnek (ék . info) ; 
FizikaiRetegnek(£s); // alkeret kuldese 


és-vár protokollról. A forrás minden keret elküldése után 
elindít egy időzítőt. Ezután várakozik addig, amíg nem 
történik valami esemény. Ilyen esemény lehet például az, 
hogy a nyugta visszaérkezik, illetve visszaérkezik valami, 
de átviteli hibával, vagy esetleg nem érkezik semmi, és le- 
jár az időzítő. 

Az első esetben a forrás lekérheti a következő csomagot 

a hálózati rétegtől, invertálja a sorszámot (ha 0 volt, akkor 
1 lehet, vagy pedig fordíva), és továbbadja a fizikai réteg- 
nek. Ha azonban sérült nyugta, vagy éppen semmi sem 
érkezik, akkor ismét az előző csomagot küldi, és a sorszá- 
mot sem írja felül. 

A vevő minden beérkezett keretet megvizsgál, hogy egész 
véletlenül nem-e duplikátum. Erre szolgál a ,vart keret" 
változó. Ha a beérkező keret sorszáma nem egyezik meg 
ennek a változónak az értékével, akkor biztos, hogy dupli- 
kátumról van szó. 


Ráültetés (pigygybackiny) 

Eddig olyan helyzeteket vizsgáltunk, amikor csak az egyik 
fél küld adatokat a másiknak. Igaz, a második és a harma- 
dik protokoll esetében már a kommunikáció valójában két- 
irányú volt, tehát szükség volt egy olyan csatornára, ahol 
az adatok mind a két irányban áramolhatnak. 
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4. lista szimplex megall-es-var protokoll 


void KuldoO 
1 
sorszam kovetkezo keret; // a kovetkezo keret 
// sorszama 
keret k; 
csomag cs; 
esemeny e; 


kovetkezo keret - 0; // inicializaljuk 
HalozatiRetegtol(£cs);  // lekerjuk az elso 
// elkuldendo csomagot 

while (true) 
ú/ 

k.info - cs; // bemasoljuk a csomagot 

// a keretbe 
k.seg - kovetkezo keret; // beallitjuk a 
// keret sorszamat 
FizikaiRetegnek (gk); // elkuldjuk a keretet 
Idozitolndul (k.seg); // elindítjuk az 
//:1tdozTtot 

Esemenyrevar (8e) ; 

// lehetseges esemenyek: keret erkezes, 

// idotullepes, ill. chesksum hiba 

if ( e -—— keret erkezett ) // ha megerke- 

// zett a nyugta 


1 
FizikaiRetegtol(8k); // megszerezzuk a 
// nyugtat 
if ( k.ack -—— kovetkezo keret ) 
ú 
HalozatiRetegrol (€cs);  // kovetkezo 
///MEGSOMAGIKE ESTE 
inc(kovetkezo keret); // invertaljuk a 
// sorszamot 
3 
3 
3 


void VevoO 
í 
sorszam vart keret; 
keret k, nyugta; 
esemeny e; 
// mivel itt mar megserulhetnek a keretek, 
// ezert a cheksum hiba is 
// lehetseges esemeny 


vart keret - 0; 
while(Ctrue) 
(6 
Esemenyrevar (8e) ; 
if ( e -—— keret erkezett ) 
jú 
FizikaiRetegtol (8k); // megszerezzuk a 
// keretet 
if ( k.seg —— vart keret ) // ha erre a 
//keretre vartunk 
ú 


HalozatiRetegnek(€k. info); // atadjuk a 
// halozati retegnek 
inc(vart keret); //legkozelebb mar a 
//masik sorszamra varunk 
3 


nyugta.ack -— 1 - vart keret; // melyik 
// keretnek a nyugtaja 
FizikaiRetegnek (8nyugta); // elkuldjuk a 
// nyugtat 
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Ilyen csatornát a legegyszerűbben úgy csinálhatunk, hogy 
két egyirányú csatornát teszünk egymás mellé, csak vég- 
pontjaikat , fordítva" kötjük be. Az egyik dróton tehát A-ból 
B-be, a másikon pedig B-ből A-ba áramolhatnak az adatok. 
Ez azonban meglehetősen pazarló megoldás, mivel egy- 
részt a sávszélesség nagyrésze kihasználatlan marad, 
másrészt a felhasználó két áramkörért fizet, de kapacitás- 
ban annyit kap, mintha egyet használna. 

Az ideális megoldás nyilván az, hogy egy áramkört haszná- 
lunk az oda és visszamenő adatok továbbítására. 

Erre láttunk példát az előző két protokoll bemutatásakor is. 
Ilyenkor az A-ból B-be, és a B-ből A-ba tartó adatok egy- 
mással összekeverednek. 

Amikor a B állomás is küld adatokat az A-nak, akkor mind- 
két félnek meg kell tudnia különböztetnie az adat- és 

a nyugta kereteket. Erre szolgál a keret fejlécében elhelye- 
zett ,kind" mező. 

A hatékonyságot azonban még tovább is növelhetjük, 
például úgy, hogy a vevő nem küld minden keret beérke- 
zése után azonnal nyugtát. Csökkenthetnénk a hálózat 
forgalmát úgy, ha a nyugtát egy kifelé menő adatkerethez 
,csatoljuk". 

Ha tehát beérkezik egy keret, akkor a vevő a nyugta kül- 
désével addig vár, amíg a hálózati rétegtől nem kap elkül- 
dendő adatot. Ha ezt megkapja, akkor a nyugtát ráülteti 
a kifelé menő adatkeretre. Így a vevő két keret helyet csak 
egyet küld. Ezzel a megoldással sokat nyerhetünk, hiszen 
nem csak jobban használhatjuk ki a rendelkezésre álló 
sávszélességet, hanem a vevő oldalán kevesebb , keret 
érkezett" megszakítás váltódik ki. Ráadásul, hogy ez 
megvalósítható legyen, csak egy bitet kell módosítanunk 
a keret fejlécében. 

Ez a módszer azonban csak akkor működik, amikor 
mindkét fél végtelen mennyiségű elküldendő adattal 
rendelkezik. Ha ugyanis a vevőhöz megérkezik egy ke- 
ret, de annak hálózati rétege éppen semmit sem akar 
küldeni, akkor előfordulhat, hogy a forrás által elindított 
időzítő lejár. 

Ez pedig a kérdéses keret ismétlését fogja eredményezni, 
tehát ha időközben érkezik is adat a vevő hálózati rétegé- 
től, a nyugta már elvesztette jelentősségét. 

Megoldás lehet a jövőbelátás, azaz megjósolni, hogy a há- 
lózati réteg mikor fog adatot átadni, és a forrás időzítőjét 
ehhez hangolni. Erre azonban még a TV jós sem képes, 
ezért jobb megoldásnak tűnhet, ha a vevő inkább vár egy 
előre meghatározott ideig, majd ha addig nem kapott fel- 
adatot a hálózati rétegtől, elküldi a nyugtát egy önnálló 
keretként. 

A következő részben innen folytatjuk. Izgalmakban tovább- 
ra sem lesz hián: szó lesz a csúszóablakos protokollokról, 
végesállapotú automatákról, híres adatkapcsolati protokol- 
lokról (például a PPP-ről, amelyet az Internetben is széles 
körben alkalmaznak). 


Garzó András (garzooOinterware.hu) 

Körülbelül három éve foglalkozik Linux- és más Unix-rendsze- 
rekkel. Legjobban az operációs rendszerek lelkivilága érdekli, 
de nyitott egyéniség. Kedvenc étele a palacsinta, és van egy 
Richard nevű macskája. Minden észrevételt, megjegyzést, 
levelet szívesen fogad. 











Egy webkiszolgáló tündöklése és bukása 


A cikk első feléből megtudhatod hogyan lehet öt perc alatt HTTP kiszolgálót írni. 
A másik felében rájössz, miért nem érdemes. 


no és az ebédem. Ezeket nap mint nap az internet- 

ről szerzem be. Egészen pontosan meglátogatok 
a böngészőmmel egy olyan oldalt, ahol a web nyújtotta 
korlátlan multimédia lehetőségeket kihasználva választom 
ki a kényes ízlésemnek megfelelő programokat, híreket, fil- 
meket és feltéteket. A háttérben a böngészőm egy távoli 
web kiszolgálóval beszélget a HITP protokollt használva 
de ez engem hidegen hagy. Engem csak a pizzám érdekel. 
Viszont lehet, hogy írsz egy programot, ami egy-két admi- 
nisztrációs munkát tesz önműködővé, és jól jönne hozzá 
egy webes felület. A vezetőség talán azt se tudja, mi az az 
SSH, de szeretne új felhasználókat hozzáadni a rendszer- 
hez. Vagy csak azt akarod tudni, hogy a csillogó-villogó kül- 
ső alatt milyen fogaskerekek működtetik a webet. Mindkét 
esetben jó kiindulási pont lehet belekóstolni egy ilyen ki- 
szolgáló lelki világába. 
Az egyszerűség kedvéért egy olyan nyelvet fogunk hasz- 
nálni, ami felépítésének köszönhetően gyors alkalmazásfej- 
lesztést tesz lehetővé. Perlben fogjuk elkészíteni első szerve- 
rünket, így a fő irányelvek nem vesznek el a részletek ten- 
gerében. Ha még nem használtad ezt a szkriptnyelvet, itt az 
ideje, hogy ellátogass a 5 http:/www.perl.org/ címre. Aján- 
lom továbbá a perl kézikönyv oldalait, melyek Debian 
rendszer alatt a perl-doc csomagban találhatóak. 
Mindössze egy Perl modulra fogunk támaszkodni a fejlesz- 
tés során, ez az IO::Socket. Ez része az általános Perl könyv- 
tárnak (Standard Perl Library), így minden Perl terjesztés 
tartalmazza. A munkához tehát mindössze egy megfelelően 
telepített Perl változatra, illetve kedvenc szövegszerkesztőd- 
re lesz szükség. Utóbbiak közül grafikus felület alatt erősen 
tudom ajánlani a jedit-et (5 http:/www.jedit.org/). Számta- 
lan kényelmi funkciója mellett hihetetlen nagy számú nyel- 
vet támogat színkiemeléssel is, ezért egy próbát mindenki- 
nek megér. 
Akkor vágjunk neki! Ha már olvastad A Perl és a hálózat 
(Linuxvilág, 2002. március) című cikkemet, az első néhány 
sor nem fog meglepetést okozni. 
Az első sorban megadjuk a szkript parancsértelmezőjének 
elérési útvonalát, és kezdeti paramétereit. Ennek segítségé- 
vel a szkriptnek futtatási jogot adva, közvetlenül indítható 
parancssorból. A -w hatására minden figyelmeztető üzenet 
megjelenik az szabványos hibacsatornán (standard error). 


S zoftverfrissítések, hírek a nagyvilágból, tv-műsor, 
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Ezután két modult is használatba veszünk. Az első, 

a strict minden szabványos Perl program alapköve. En- 
nek hatására hibaüzeneteket kapunk, ha az egységesítés út- 
jára lépett nyelvben nem szép szerkezetekkel dolgozunk. 
Az IO: : Socket modul pedig a hálózatkezelést egy kelleme- 
sen használható, objektum-orientált felület mögé rejti. 


my $docroot -— "./web"; 


die "Usage: " . $0 . " (porthwn" unless (GARGV 5 0); 
A változók deklarációja kötelező, ha strict üzemmódban va- 
gyunk. Erre szolgál a my kulcsszó. A $docroot egy globális 
tartalmazza, amelyben az összes HTML állományt tárolni 
fogjuk. Ezzel ugyanazt szeretnénk elérni, mint az Apache 

a DocumentRoot direktívával. A következő sor ellenőrzi, 
hogy van-e átadott parancssori paraméter. Így várjuk 
ugyanis azt a kapuszámot, ahol a kiszolgáló figyelni fog és 
várja a beérkező kéréseket. A program használat alakját írja 
ki a képernyőre és megszakítja futását, amíg az átadott pa- 
raméterek száma nem nagyobb nullánál. Ehhez csak annyit 
kell tudni, hogy Perl alatt egy tömb (jelen esetben GCARGv) 
skalárként értelmezve a tömb elemeinek számát adja vissza. 


my $server - new IO::Socket::INET C( 
LocalPort —5 $ARGV[0], 
Proto -—5 "tcp", 
Listen -5 SOMAXCONN, 
ReuseAddr -—5 1 

pb 


die "Error creating socket.Mn" unless defined 
s $server; 


Ezután újabb két sor következik, amit csupán a könnyebb 
olvashatóság érdekében tagoltam több sorba. Előbb egy 

új változót hozunk létre, majd ellenőrizzük, hogy siker- 

rel jártunk-e. Első lépésben a new kulcsszóval az 

IO: : Socket: : INET osztályból hozunk létre egy példányt, 
melynek segítségével majd felépítünk egy TCP/IP kapcsola- 
tot. A konstruktornak egy olyan asszociatív tömböt kell át- 
adni, mely kulcs-érték párjaival leírja a felépítendő foglalat 
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(socket) típusát. A legfontosabb a parancssorban átadott 
kapuszám. A várakozási sort a lehető legnagyobbra állítjuk, 
illetve beállítjuk, hogy minden kapufoglalás előtt próbálja 
meg felszabadítani azt, ha szükséges (lásd: 

IO: : Socket: : INET(3 per1)). 


$SIG(INT3 -— sub ( 
print "Stopping WEB server." ; 
close $server; 
exit; 


Fi 


Következő lépésben a megszakítás szignálhoz (interrupt 
signal) hozzárendelünk egy névtelen eljárást, amely a ki- 
szolgáló biztonságos leállításáért felel. Ez azért szükséges, 
mert az elindított webszerver majd csak a CTRL--C billentyű- 
kombináció hatására fejezi be működését, azonban ekkor is 
fontos a biztonságos leállítás. A 95SIG szintén egy asszociatív 
tömb, melyet a szignálok rövid neveivel lehet indexelni, és 
minden szignálhoz egy függvényt rendel. Jelen esetben 
CTRL--C esetén kiírja a képernyőre az elköszönő üzenetet, 
lezárja a program elején nyitott foglalatot, majd kiszáll. 
print "Starting WEB server (port " . $ARGV[0] 
ka, INN 


for (my $client; $client - 
sclose $client) ( 


$server -s accept 0; 


hi 


Ez a ciklus lesz a kiszolgáló lelke. A ".. operátor hatására 
összefűzött karakterfüzér megjelenítése után valójában egy 
végtelen ciklus indul el. Ebből csak szignálok használatával 
lehet kilépni. A ciklus kezdetekor deklarálunk egy $client 
nevű változót, mely a csatlakozó ügyfél foglalatát fogja tá- 
rolni. Minden iteráció elején meghívjuk a $server objek- 
tum accept O elemfüggvényét. Ez addig nem adja vissza 
a vezérlést, amíg egy új ügyfél nem érkezik. Ekkor felépíti 
a kapcsolatot, és visszaadja a kliens foglalatát. Az iteráció 
végén, amikor az ügyfelet kiszolgáltuk, ez utóbbit természe- 
tesen le kell zárnunk. 


print localtime O Connect from 


sm , $client -s peerhost O . "mm"; 
my $line - -c$clients; 
print 7" " . $line; 


print localtime O closing connection." ; 

A ciklus minden letutásának elején kiszolgálóoldalon kiírat- 
juk az aktuális dátum mellett az ügyfél csatlakozásának té- 
nyét, illetve IP-címét. Ezt az adatot a $client objektum 
peerhost O elemfüggvényével határozzuk meg. Ezután 
fogadjuk az ügyfél kérését, ami azt jelenti, hogy egy sort ol- 
vasunk be a kliens foglalatról a gyémánt (diamond) operá- 
tor segítségével. Ezt a $line változóban tároljuk, és szemlé- 
letesség kedvéért azonnal ki is íratjuk a kiszolgáló oldalán. 
Természetesen az iteráció végén a kapcsolat lezárásának té- 
nye is megjelenik a képernyőn. 
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if ($line —- /AGET C(.") HTTP."Wr$/) ( 
my $file -— $1; 
$file .- "index.html" if ($file —- 
5 /4$/; 
print $client "HTTP/1.0 200 OKWW" ; 
print $client "Server: BigWig WEB 
s serveren; 
print $client "Connection: closer"; 
print $client "Ccontent-Type: 
5 text/html; 


: 


Csak az ügyfél legegyszerűbb GET kéréseit dolgozzuk fel. 
A $1ine változót, amely a kliens által küldött sort tartal- 
mazza, próbáljuk meg az -- operátorral egy reguláris 
kifejezésre illeszteni. A "/ jelek között szereplő kifejezés 

a GET /eleresi ut/file HTTP/x.x alakra illeszkedik, 
ahol x.x a protokoll változatszáma. A feltételes szerkezet 
magjába akkor lép be, ha a minta illeszkedett, sőt mi több 
a $1 változó a zárójelezett . " miatt tartalmazni fogja 

a kért állományt. Ezt egy $file változóba helyezzük át 
az átláthatóság és a módosíthatóság végett, és a végére 
illesztünk egy , index.html" szöveget, ha "/ jelre végző- 
dik. Továbbá kiíratjuk a szabályos HTTP fejlécet az ügyfél 
oldalára. 


$file - $docroot . $file; 
if (-f $file and -r $file) ( 
print " Serving " . $file . "nm"; 


open (INPUT, $file); 
while (cINPUT2) ( print $client $. 
nm; 3 
close (INPUT); 

l else ( 
print " 404 Not foundw"; 
print $client "-HTML3--xHEAD3cTITLEZ 
ar ; 
print $client 7404 Not foundwrn"; 
print $client 
53" L/TITLE3c/HEAD5-ABODYAÁWTM" ; 
print $client "cFONT size-425Sorry, 
5 the page your"; 
print $client "have reguested cannot 
sbe found"; 
print $client "7ca/FONT3c/BODY3c/HTML5 
ar; 


; 


Végezetül az állománynév elé tesszük a főkönyvtár elérési 
útját, ellenőrizzük a file meglétét, és kiíratjuk az ügyfélnek. 
A -f és -r különleges függvények (lásd per1funcC(1)). 
Nemnulla visszatérési értékkel jelzik, ha a file közönséges, 
illetve ha olvasható. Ez esetben megtesszük a szokásos be- 
jegyzést kiszolgálóoldalon, megnyitjuk az állományt, soron- 
ként kiíratjuk, majd lezárjuk. Ellenkező esetben pedig egy 
olyan HTML oldalt nyomtatunk a kliensnek, ami arról tájé- 
koztatja, hogy a keresett oldal nem található. Ennek megfe- 
lelően már egy kis HTML tudással tetszőleges dinamikus 
tartalom is készíthető. 











print 
print $client 
print $client 


Creating dinamic content.Mn"; 
" SHTML35cHEADS-TITLESWT" ; 
"Dinamic pagewr" ; 
print $client 7c/TITLE3c/HEAD3-CBODYAÁT" ; 
print $client "c-TABLE border-iSr" ; 
for (my $i -— 1; $i cz 10; $ir3) ( 

print $client "7-cTR5"; 

for (my $j - 1; $j cz 10; $jra) ( 


print $client "c-TD2" . $i " $j 
a" 2/TDD"; 
3 
print $client 7-2/TRAVN" ; 
3 
print $client "7c4/TABLE3c/BODY35c/HTML: 
nt ; 


A fenti példa dinamikusan hoz létre egy 10x10-es szorzó- 
táblát. Látható, hogy a HTML fejléc kiíratása után egy ket- 
tős for ciklussal készítjük el a táblázatot. A külső végigmegy 
a sorokon, és a belső kitölti azokat. Csak arra kell figyelni, 
hogy a nyomtatás ne a szabványos kimenetre (standard 
output) történjen, hanem az ügyfél foglalatára. Az eddigi 
példákból könnyen látható, hogy a foglalatok ugyanolyan 
egyszerűen írhatók-olvashatók, mint a közönséges file- 
leírók (file handler). 

Utóbbi, dinamikus rész úgy van beillesztve, hogy még 

a kiszolgálás előtt történik egy esetszétválasztás. Ha 

a kérés ,/dinamikus/index.html"-re vonatkozik, ez a rész 
fut le, egyéb esetben az állomány kiíratása. Tetszőleges 
böngészővel a http://localhost:port/eleresi ut címre mutat- 
va érhetjük el a helyi gépről a kiszolgálót, de ne felejtsük 
el, hogy a hálózat tetszőleges pontjáról megtalálható 

a megfelelő cím megadásával. A mellékelt képen jól lát- 
ható, hogy kiszolgálónk támogatja az összes népszrű 
böngészőt. 


Ha ez mind ilyen szépen működik, akkor mi a haj? 

A kiszolgáló első és legszembetűnőbb hibája, hogy Perlben 
íródott. A Perl egy szkriptnyelv, vagyis nem előrefordított. 
Nagy terhelés mellett nem nehéz megfektetni egy szervert, 
amely olyan nyelven íródott, ami futásidőben értelmeződik. 
Valódi, nagy erőforrásigényű alkalmazásokat érdemes in- 
kább C/C-----ban készíteni. Ez a példa viszont egy állator- 
vosi ló. Azért íródott Perlben, hogy a legfontosabb részek jól 
felnagyíthatók legyenek, és ne zavarjanak minket az apró 
részletek. Ha az irányelveket elkaptad, nézz utána, hogyan 
írhatnád meg ugyanezt pl. C-ben. 

Sajnos a szerverünk a dinamikus tartalom készítése mi- 
att HTML kódot tartalmaz! Ez egy súlyosan hibás elgon- 
dolás. Valamivel tűrhetőbb megoldás lett volna, ha az ol- 
dal készítését egy külső szkriptre bízzuk, a szerverünk- 
nek így azt csak meghívnia kellene. Ezt az eljárást hívják 
CGI-nek (Common Gateway Interface), amikor egy külső 
program készíti a teljes választ az ügyfél GET kérésére. 
Ez azonban szintén egy túlhaladott elképzelés, ma 

már sokkal szívesebben használnak oldalba ágyazott 
szkripteket (ilyen a PHP). 

A szerver nem tud egy időben egynél több ügyfelet kiszol- 
gálni. Ha két kliens egyszerre csatlakozik, előbb a gyorsab- 
bat kiszolgáljuk, ezalatt a másik várakozási sorba kerül 
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(listen gueue). Ezt nagyjából úgy lehet elképzelni, mint egy 
fogorvosi rendelőt, amelyben egyetlen orvos van. A váró- 
szoba méretét adhattuk meg a $server objektum létrehozá- 
sakor a Listen paraméterrel. Ahhoz, hogy több orvosunk 
legyen, gyermek folyamatokat kellett volna létrehozni 
minden egyes csatlakozó ügyfélnek, ám ez szintén elbonyo- 
lította volna a példát. Ha ennek a mikéntje érdekel, olvasd 
el a vonatkozó kézikönyv lapot: perlforkC1). 

Elég gyermekded módon bántunk a hibakezeléssel is. 

Ha az állomány nem létezik, a HTTP szabvány szerint nem 
szabad OK kódot adni az ügyfélnek. Mi a HTTP fejlécben 
kiadtunk egy HTTP 200 OK-t, majd nyomtattunk egy olyan 
HTML oldalt, ami leírja, hogy mennyire sajnáljuk, amiért 
nem tudjuk kiszolgálni. Már a fejlécben illett volna 404-es 
kóddal jelezni, hogy az oldal nem található. Ezeket a dolgo- 
kat nem szabad elnagyolni, mert a szabványtól való eltérés 
miatt semmi sem garantálja, hogy a böngésző tényleg meg- 
jeleníti a tartalmat. 

Egy portál gyakran tartalmaz képet. Máskor hangot, vide- 
ót, flash animációt, letöltésre váró állományt. A sokféle 
tartalom egységes kezelésére találták ki a MIME informá- 
ciót. Ez is a HTTP fejlécben utazik, és egy főcsoport/alcso- 
port formában szöveges leírással szolgál az adott állo- 
mányról. Mi egyszerűen azt mondtuk, hogy minden 
text/html. Ennek az az eredménye, hogy ha egy képet 
kér egy kliens, azt is ezzel a MIME jelzéssel adjuk át, 
ezért nem a kép fog megjelenni a böngészőben, hanem 

a bináris tartalom. 

Végül, de nem utolsó sorban alapvető biztonsági hibá- 

tól szenved a szerver. A főkönyvtáron kívüli tartalom is 
elérhető, mindössze olyan GET kérést kell fogalmazri, 
amely kellő számú ,,.."-t tartalmaz.Mivel ez nem valódi 
chroot, ezért elég a böngésző címsorába azt írni, hogy 
http://localhost:port/ . . /web.pl, és máris olvasha- 

tó a webszerver forrása. Ez azonban nem az egyetlen 
olyan információ, amely bizalmas lehet, gondoljunk 

csak /etc/ passwd állományra, amely bárki számára 
olvasható lesz, amint a támadó eltalálta a megfelelő 
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Ha ez ennyire rossz, akkor mire volt jó? 

Okos ember mások hibáiból tanul — szokták mondani. 

Ha ez egy informatikusra igaz, az hatalmas szerencse min- 
denkinek. Olvass utána azoknak a részeknek, amelyekről 
most hallottál először. Utána próbáld meg átírni a szervert 
úgy, hogy eggyel kevesebb hiba legyen benne - legyen az 
elvi, kényelmi, vagy biztonsági. 

A fő az, hogy meglásd a saját kódodban is az ilyen hibá- 
kat és arra törekedj, hogy kijavítsd őket, ahelyett, hogy 
elfednéd. 


Írj bátran, ha kérdésed van. 
Sok sikert és örömet a kísérletezgetéshez! 


Fülöp Balázs (ladmineoguardware.com) 

Imádja a Túró Rudit, a Debian Linuxot 

és a teheneket. Kedvenc írója Slawomir Mrozek. 
Leginkább a számítógépes hálózatok biztonsága 
érdekli. A BME VIK műszaki informatikus 

szak hallgatója. 
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gy mm , z- 
A Sudo-ról dióhéjban 


... avagy hogyan indíthatjuk programjainkat álnéven? 


izonyára minden rendszergazdában felvetődött 
1 már a probléma, hogy hogyan lehetne azt megolda- 

ni, hogy bizonyos kitüntetett felhasználók elindít- 
hassanak bizonyos védett programokat, amelyekhez külön- 
leges jogosultságok szükségesek, s mindezt anélkül, hogy 
az adott felhasználónak meglenne ez a különleges joga. Ez 
a leggyakrabban akkor fordul elő, amikor bizonyos folya- 
matokhoz - például adatbázis mentéséhez - root jogosult- 
ságra van szükség, tehát csak a rendszergazda végezheti. 
A rendszergazdának azonban a legritkább esetben feladata 
az ilyen folyamatok indítása, tehát el kell látni a megfelelő 
felhasználót az adott jogosultsággal. Ez azonban veszélyes, 
mert ezzel a felhasználó akár szándékosan, akár figyelmet- 
lenségből kárt okozhat. Ősidők óta létezik a problémára egy 
megoldás: a setuid/setgid használata, amelyet az egyes 
fájlokra határozhatunk meg Posix környezetben. Ha pl. 
a setuid bit be van állítva egy állományra, akkor azt bárki 
futtatja, aprogram azon felhasználó jogaival fog futni, akié 
az állomány. Tipikus példája ennek a passwd parancs, 
amely azáltal tudja írni a jelszófájlt, hogy a parancs tulajdo- 
nosa a root felhasználó, s be van billenve a setuid bit. Nem 
nehéz azonban rájönni, hogy ezt alkalmazva mondjuk az 
adatbázis-mentés példára azt kapjuk, hogy minden (leg- 
alábbis nagyon sok) felhasználó tudja futtatni az adott pa- 
rancsot, nem csak az, akit a rendszergazda szeretne. 
A probléma tehát az, hogy nem lehet elég finom felbontás- 
ban engedélyezni bizonyos parancsok futtatását ezzel 
a módszerrel. 


A megoldás: Sudo 

Ennek a kis programocskának a segítségével lehetőségünk 
nyílik arra, hogy az előre meghatározott szabályok szerint 
bizonyos felhasználók bizonyos programokat root vagy 
más felhasználó nevében futtathassanak. Az, hogy ki, mit és 
hogyan futtathat, a program beállítási fájljában kell rögzíte- 
nie a gép rendszergazdájának, és ezzel máris megoldódott 
a problémánk: akár felhasználónként és parancsonként 
egyesével is meghatározható, hogy ki és mit indíthat. A do- 
log a hétköznapi használatban úgy működik, hogy a pa- 
rancs helyett a sudo cparancsz utasítást adjuk ki az értel- 
mezőnek. A Sudo ekkor ellenőrzi a felhasználó és a parancs 
összerendelését, s a megfelelő feltételek mellett elindítja 

a programot úgy, mintha azt valóban az adott parancs fut- 
tatására jogosult személy tette volna, s a futás végén vissza- 
tér az elindított parancs visszatérési értékével. 
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A programról 

A Sudo alapértelmezetten része szinte minden ma haszná- 
latos terjesztésnek, így tehát csak annyi a dolgunk, hogy 

a rendszer csomagkezelőjével megkeressük, és hozzáadjuk 
a telepített összetevők sorához. Ha valamilyen oknál fogva 
ez nem sikerülne, még mindig letölthetjük a legfrisseb vál- 
tozatot az alkalmazás honlapjáról 

(2 http:/www.courtesan.com/sudo/) — igaz, csak forrás for- 
májában. A binárisok csak nagy kereskedelmi Unix változa- 
tokhoz érhetők el. 

A telepítésről tehát ennyit. A Sudo beállításai az általam 
használt Debian, Red Hat ill. SuSE terjesztésekben kivétel 
nélkül a /etc/sudoers fájlban találhatók. Nekünk szinte min- 
dig ezzel a fájllal kell majd dolgozni ahhoz, hogy 
testreszabjuk a programunkat. 


A Sudo használata 

A már fentebb említett sudo cparancsz stílusú használat 
esetén alapértelmezetten meg kell adnunk a saját felhasz- 
nálói jelszavunkat. A helyes jelszó megadása esetén egy 

5 perces érvényességű jegyet kapunk, ami azt jelenti, hogy 
a parancs következő 5 percben történő ismételt futtatása 
esetén nem kell a jelszót újra beírni. Ezzel a megoldással 
szerették volna a program írói megakadályozni azt, hogy 
egy otthagyott parancsértelmezőbe illetéktelenek bármit be- 
irkálhassanak. A jegy érvényességének ideje természetesen 
átállítható, mint ahogyan a jelszó megadásának kötelező 
volta is, akár minden parancsra egyesével — mindezt 

a sudoers fájlból. A program nevéből is adódóan 
(SUperuser DO!) alapértelmezetten root-ként próbálja meg 
futtatni a kívánt parancsokat, de ettől a megfelelő kapcso- 
lók használatával eltérhetünk. A lényeg az, hogy ha nem 
rendszergazdaként használjuk a Sudo-t, akkor minden ki- 
adott parancs mögött kell, hogy legyen valami a /etc/sudoers 
fájlban, különben a program nem fog lefutni. 

A Sudo egyébként igen aktívan naplóz. Naplózza a pró- 
bálkozásokat és a sikertelen futtatási kísérleteket, de igény 
szerint rögzíti a sikeres próbálkozásokat is. Ha valaki 
olyan próbálkozik, akinek nincs joga a sudoers szerint 

az adott parancshoz, még levelet is küld — alapértelme- 
zetten a root felhasználónak. A programnak egyébként 
rengeteg átállítható alapértelmezett beállítása van. 

Hogy megtudjuk mennyi, adjuk ki a sudo -L parancsot. 

S ha már a parancsoknál tartunk, nézzünk meg egy-két 
gyakrabban használt darabot. 











sudo -1: Ezzel a paranccsal kilistázhatjuk, hogy nekünk, 
mint felhasználóknak milyen parancsok futtatásához van 
jogunk a sudo segítségével. 

sudo -v: Felülírja a Sudo-tól legutóbb kapott jegyet, amely 
ugye a futtatás során jön létre, majd avul el, stb. Ha szüksé- 
ges, bekéri a jelszót. Ezzel gyakorlatilag azt jelezhetjük 

a sudo számára, hogy még a gép előtt vagyunk, ezáltal a je- 
gyünk újabb n percig érvényes — ugyanez történik egyéb- 
ként akkor is, ha futtatjuk az adott parancsot. 

sudo -k: Érvényteleníti az jegyet, amit a legutóbbi futtatás 
során kaptunk, tehát más még véletlenül sem indíthatja el 
az adott parancsot, ha esetleg kijelentkezünk, vagy otthagy- 
juk a terminált. 

sudo -b cparancsz: Ennek hatására a kért parancs a háttér- 
ben fog futni. Ez akkor lehet hasznos, ha valami hosszan 
futó folyamatot indítunk, de közben szeretnénk visszakap- 
ni a promptot. 

sudo -u cfelhasználós cparancsz: Ez esetben nem root- 
ként próbálja meg futtatni a parancsot, hanem a megadott 
felhasználó nevén. 

Ezeken túlmenően még számos kapcsolót használhatunk, 
héjprogramot jelölhetünk ki, másik sajátkönyvtárat adha- 
tunk meg, és még sorolhatnám. A kedves olvasó a prog- 
ram telepítése után a sudo kézikönyvben (man sudo) 
olvashat róla. 


A Sudo testreszabása 

Mint már említettem, a Sudo testreszabása a /etc/sudoers fáj- 
lon keresztül történhet. A programnak része egy olyan pa- 
rancs is, amellyel ezt a fájlt lehet szerkeszteni, ez pedig 

a visudo. Gyakorlatilag a rendszer alapértelmezett szöveg- 
szerkesztőjét hívja meg, ám láthatatlanul azért csinál mást 
is a háttérben: Lezárja a sudoers fájlt a többi folyamatok 
elöl, így azok nem férhetnek hozzá, tehát nem fordulhat elő 
az, hogy egyszerre ketten egymásnak ellentmondásos érté- 
kekkel töltik fel az állományt. Ezen túl a szerkesztés után 

a parancs ellenőrzi a fájl tartalmát, és csak akkor menti el, 
ha nincs benne szintaktikai hiba. Ha van, akkor újra szer- 
keszthetjük a fájlt, vagy eldobhatjuk a változtatásokat, kivé- 
teles esetben megkérhetjük rá, hogy a szintaktiai hiba elle- 
nére is mentse el a változtatásokat. 

Maga a sudoers egyébként az EBNF (Extended Backus-Naur 
Form) nyelvet használja, ezen a nyelven kell tehát monda- 
tokat a sudoers fájlba beírni, s ezt tudja értelmezni a prog- 
ram. Nekünk szerencsére nem kell megijednünk ettől a le- 
írónyelvtől, ugyanis egyrészt nagyon egyszerű, másrészt 

a mindennapi használat során a példamondatok átalakítása 
bőven elég ahhoz, hogy elkészítsük a számunkra szükséges 
kifejezéseket. Ha szükségesnek érezzük, a nyelv gyorstalpa- 
lója megtalálható a sudoers kézikönyvében (man sudoers), 
sok más egyéb hasznos tudnivaló mellett. 

A fájl kétféle adatot tartalmaz. Egyiküket alias-nak nevezi 

a leírás — ezek valójában globális változók. A globális válto- 
zók egy részével felhasználói ill. parancscsoportokat hozha- 
tunk létre, másik részével beállíthatjuk a már fentebb emlí- 
tett alapértelmezett értékeket: mi legyen az alapértelmezett 
héjprogram, mi legyen az alapértelmezett sajátkönyvtár, és 
még sorolhatnám... 

A másik csoportja az adatoknak a felhasználókra vonatkozó 
előírások. Ezek mondják meg, hogy egy adott parancsot 
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mely felhasználó indíthat el és milyen körülmények között. 
A sudoers fájlban használt leírónyelv lehetővé teszi, hogy 

a kialakított felhasználói csoportokkal, munkaállomás-cso- 
portokkal, parancs-csoportokkal nagy számú felhasználótá- 
bort is könnyedén kezelhessünk, mi több a munkaállomás- 
csoportok alkalmazásával az is megoldható, hogy ugyanazt 
a sudoers fájlt használjuk egy hálózat több gépén is. Ez 

a gyakorlatban nagyjából a következőképpen működik: 
megadjuk, hogy mely munkaállomáson futtatható csak az 
adott parancs, ezáltal ha másik gépre másoljuk, ott az azo- 
nos nevű felhasználó nem fogja tudni indítani az adott pa- 
rancsot. Ezt általánosítsuk most gondolatban mind a paran- 
csok terében, mind a fizikai elhelyezkedés terében, s máris 
megkapjuk egy központosított rendszer körvonalait, amely- 
ben egy helyről szabályozható igen finom felbontásban az 
egész géppark felhasználótábora. 

Végezetül nézzünk néhány egyszerű példát, amire nekünk, 
egyszerű felhasználóknak is szüksége lehet. Mindenekelőtt 
vizsgáljuk meg, hogyan is néz ki egy felhasználóra vonat- 
kozó előírás: 


cfelhasználósz cmely gépeken futtatható: - 
s [(cmilyen néven futtatható:)] 
cparancskL: , cparancs25 , . . . . 


Mint látjuk, tényleg nem valami bonyolult dolog. Amit 
érdemes még tudni: létezik egy ALL kulcsszó, amely annyit 
tesz a mondatban is, hogy "minden esetben". Említettem 
még, hogy kikapcsolható a jelszó bekérése a Sudo használa- 
ta esetén. Ez az első parancs elé biggyesztett NOPASSWwD: 
kulcsszóval érhetjük el. Ha azt szeretnénk, hogy csak bizo- 
nyos parancsok esetében ne kelljen megadni jelszót, akkor 
a bizonyos parancsok" felsorolása után a többi parancs elé 
tegyük a PASSWD: kulcsszót. Ezzel körülbelül el is mondtam 
mindent, amire otthoni, vagy egyéb kisebb környezetben 
szükségünk lehet, lássuk a példákat: 

bela ALL -— (ALL) ALL: Ez a sor a sudoers-ben bela-nak gya- 
korlatilag root jogot ad anélkül, hogy Béla ismerné a root- 
jelszót. Minden parancsot futtathat mindenki nevében, 
minden gépen. 

bela ALL — (ALL) NOPASSWD: ALL: Ez a sor akkor jó, ha ott- 
hon a munkaállomást felhasználóként hasznájuk, de gyak- 
ran szükséges root jog az egyes parancsokhoz. Ilyenkor ké- 
nyelmetlen volna mindig su parancs után begépelni a jel- 
szót, stb, ezért beírhatjuk a fenti sort a /etc/sudoers-be, s ké- 
nyelmesen gépezhetünk egész nap. 

bela konyveles - /usr/bin/db. backup: Béla a konyveles 
nevű gépen futtathatja az adatbázis-mentést elvégző 
scriptet root-ként, de ezen kívül semmi mást, és meg kell 
adnia a parancs kiadása után a jelszavát. Ezek alapján már 
bárki könnyedén behelyettesítheti a kívánt felhasználó-pa- 
rancs összerendeléseket, s hozzáolvasva a felhasználói leírá- 
sokból (man) már egész kis rendszer kialakítására képes. 


Komáromi Zoltán 
(komi(okiskapu.hu) 

23 éves, a BME hallgatója, mellette 
PHP-programozóként dolgozik. 
Kedvenc területe a multimédia. 
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GRUB rendszertöltő - az alapoktól kezdve (1. rész) 


A LILO letaszíttatott trónjáról, lássuk az új uralkodó képességeit. 


olyan fontos a működés szempontjából, mint maga 

a rendszermag. A rendszertöltő ugyanis a legelső 
felhasználói program, amely a gép indítását követően elin- 
dul. Feladata az operációs rendszer alapvető összetevőinek 
betöltése, majd a vezérlés átadása a már ébredező operációs 
rendszernek. Azt gondolhatnánk, hogy ez nem nagy fel- 
adat, és valóban: egy rendszermag betöltése nem a világ. 
Gondoljunk bele azonban abba, hogy az esetek többségé- 
ben több eltérő felépítésű operációs rendszerünk van, me- 
lyeket felváltva szeretnénk használni — s mindeközben jó 
lenne, ha nem kellene egynél több rendszertöltőt alkalmaz- 
ni. Ezen kívül minden haladó felhasználó vágya, hogy ne 
kelljen elpusztulni a rendszertöltő beállítása közben, egy- 
szerű legyen, és ha kell mindenféle extra trükköt meg le- 
hessen vele csinálni, vészhelyzetben fel lehessen éleszteni 
a gépet, és ehhez ne kelljen fejből tudnia, hogy mi merre 
található a gépen. A fentiek egy nagy rugalmasságot bizto- 
sító, mindenféle környezetben működő, sokféle operációs 
rendszert indítani képes, , felhasználóbarát" rendszertöltőt 
igényelnek. Mindezt egyben megtestesíti a GRUB (GRand 
Unified Bootloader — Nagyszerű, Egységesített Rendszertöl- 
tő), amely ugyan még csak a 0.94-es változatánál tart, máris 
átvette az uralmat a régi, meglehetősen merev LILO-tól. 


s okan megfeledkeznek róla, de a rendszertöltő épp 


A GRUB tulajdonságai 

Alapvető különbség a LILO-val szemben, hogy a GRUB 
nem kifejezetten Linux betöltéséhez íródott, hanem 
,Multiboot Standard"-nak megfelelő operációs rendszerek 
indításához, mint például a GNU/Hurd. Ezek mellett ter- 
mészetesen be tudja tölteni a Linux és mindenféle BSD 
rendszereket is — és ezzel a sornak még mindig nincs vége. 
Hasonlóan elődjéhez a LILO-hoz, ez is használja a láncolt 
betöltés (chainload) módszerét, amellyel képes betölteni 
mindenféle kereskedelmi operációs rendszerek magját. 
Alapvető előnye minden eddigi rendszertöltőhöz képest, 
hogy a GRUB közvetlenül ismer jó néhány fájlrendszert, 
ahonnan fájlszinten képes elérni a betöltendő modulokat, 
rendszermagot. Ennek az előnye, hogy nem igényli a betöl- 
tendő fájlok fizikai helyének ismeretét, így nem kell folyton 
újratelepíteni, ha új rendszermagot fordítunk. Ha a régi 
nem indulna el, akkor egy egyszerű parancssor segítésével 
tetszőleges, a merevlemezen megtalálható rendszermagot 
a gép indításakor közvetlenül betölthetjükk. Ha pedig már 
itt tartunk, tegyünk említést a GRUB méltán népszerű héj- 
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programjáról. Ez a rendszerindításkor egy menüvel párhu- 
zamosan a felhasználó rendelkezésére áll. Az elérhető né- 


hány tíz parancs segítségével szinte minden problémát or- 
vosolni tudunk - még a GRUB azonnali, más eszközre való 
telepítése is megoldható. 

Említettem a menüt: a LILO-hoz hasonló szöveges menü 
áll rendelkezésünkre, amely az előre beállított paraméterek- 
nek megfelelően tartalmazza a betölthető operációs rend- 
szerek nevét és indításának módját. 











A GRUB felépítése és működése 

A GRUB három, egymástól élesen elhatárolható fokozatból 
(stage) áll: az első rész egy 512 bájt méretű programkód, 
amely a merevlemez fő rendszerindító területére (Master 
Boot Record — MBR) íródik. Ez semmi mást nem csinál, mint 
betölti a következő fokozatot, amely hivatalosan a másfele- 
dik sorszámot viseli. Ez még mindig egy viszonylag kis mé- 
retű rész, amely azonban már képes értelmezni egy adott 
fájlrendszert, és ezáltal el tudja érni a merevlemez adott le- 
mezrészén található második fokozatot. Ez az utolsó foko- 


zat tartalmazza tulajdonképpen magát a GRUB-ot. Itt van 
kódolva az összes fájlrendszer ismerete, a tényleges rend- 
szerbetöltő, valamint a már emlegetett héjprogram, 

amellyel képesek vagyunk parancsokat kiadni a rendszer- 





töltés kényes folyamatát szabályozva ezzel. Azért kell ilyen 
apró szakaszokra bontani a rendszertöltőt, mert az MBR- 
ben, illetve közvetlenül ezt követően nagyon kevés hely 
van, és nem férne el egy ekkora tudású program. Az MBR 
mérete pontosan 512 bájt, ide kerül hát az a program, ame- 
lyik tudja, hogy hol található az ő folytatása. A másfeledik 
fokozat még mindig korlátozott hellyel bír, ide sem fér el 

a teljes GRUB, de az már igen, hogy képes legyen megke- 
resni fájlszinten az adott lemezrészen, így nem függ az 
utolsó fokozat fizikai helyétől a rendszertöltő terület tar- 
talma. A harmadik fokozat pedig már akármekkora lehet 

— figyelembe véve természetesen a rendelkezésre álló 
memória adta korlátokat. 


A gép bekapcsolása után... 

Először a gép BIOS-a betölti az MBR-ben található 512 báj- 
tos kódot, amely jelen esetben a GRUB első fokozata. A fo- 
kozat hivatkozik az őt követő második fokozatra. Ez a rész 
nem mindig töltődik be, de ha meghívásra kerül, akkor ez 
lesz az a fejezet a történetben, amely ismeri azt és csak azt 
a típusú fájlrendszert, amilyenre a GRUB többi része tele- 
pítve van. Nem nehéz kitalálni, hogy minden ismert fájl- 
rendszerhez létezik egy fokozat, s telepítéskor a megfelelő 
kerül a helyére. Az utolsó fokozat pedig maga a rendszer- 
töltő, benne a legfontosabb résszel: a vezérlést átadó prog- 
ramkóddal. A telepítés során, ha nem használjuk a másfele- 
dik fokozatot, akkor a második fokozat fizikai elhelyezkedé- 
se az első fokozatban rögzítődik, ellenkező esetben a másfe- 
ledik rész fizikai címe kerül az MBR-be, s a másfeledik rész- 


A GRUB újításai a menü és a héjprogram 

A GRUB-ban található héjprogram egyrészről lehetővé 
teszi, hogy nekünk ne kelljen részletesen ismernünk a gé- 
pünkön található rendszereket pusztán azért, hogy hiba 
esetén is el tudjuk indítani a gépünket; másrészről azt is 
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megengedi, hogy végrehajtsunk bizonyos műveleteket 
anélkül, hogy a rendszerünk elindult volna. Ez igencsak 
meglepő annak ismeretében, hogy eddig a rendszertöltés 
folyamán gyakorlatilag nem volt beleszólásunk az esemé- 
nyek alakulásába. 

Az előző rendszerleállítást megelőzően kellett a betöltési 
jellemzőket precízen megadni, ellenkező esetben sanszos 
volt, hogy a gépünk nem indul többé. A GRUB a héjprog- 
ramja segítségével nem csak a betöltési paraméterek részle- 
tes átállítását teszi lehetővé, de megenged sok-sok rend- 
szerszintű hívást is, mintha csak egy konkrét operációs 
rendszert használnánk. Ez a GRUB felhasználói oldalának 
alacsony szintje. 

Minden ebben a parancssorban kell, hogy ,lefusson". Ké- 
nyelmetlen lenne azonban minden rendszerindítás során 
kézzel megadni, hogy melyik lemezrészről szeretnék betöl- 
teni, s milyen jellemzőkkel, ezért létezik erre a célra egy 
menü. Tudom, azt írtam, ez egy újítás, pedig ilyen már 

a LILO-nál is létezett. Van azonban egy elég nagy különb- 
ség: a GRUB esetében a menüpontok nincsenek , beledró- 
tozva" a rendszertöltő területen található kódba. A GRUB 
ugyanis fájlszinten éri el a merevlemezen található menüál- 
lományt. Ez tartalmazza az általunk előre megadott indít- 
ható operációs rendszereket és még más beállításokat is. Az 
egyes menüpontok valójában parancsgyűjtemények, gya- 
korlatilag ide írhatjuk be előre azokat a parancsokat, ame- 
lyeket a rendszerindítás során kellene mindig kiadnunk, te- 
hát a menüpont kiválasztása során a szükséges parancsok 
automatikusan , begépelődnek", aminek hatására megtörté- 
nik a rendszer betöltése — ennyi a menü titka. Ha van menü 
definiálva, akkor alapértelmezetten az jelenik meg indulás- 
kor, ha pedig nincs, akkor a GRUB , parancssor". Előző eset- 
ben is lehetőségünk van váltani a menüs és parancssoros 
nézet között, így válik lehetővé, hogy akár minden indítás 
során hegeszteni tudjuk a masinánkat. 


Rendszertöltés a hálózatról? 

Igen, a GRUB ezt is tudja. A parancssor lehetővé teszi, hogy 
akár kézzel, akár DHCP-n keresztül beállítsuk a gépünkben 
található hálózati eszközt, megadjuk a boot-kiszolgálót, 
ahol a rendszermag található, ezt követően pedig TFTP 
protokollon keresztül letölthessük az adott rendszermag- 
állományt, s el is indítsuk azt a gépünkön. Ez a megoldás 
akkor lehet hasznos, ha központilag szeretnénk tárolni, cse- 
rélgetni a rendszermagot, hogy ne kelljen az adott géphez 
ülni azért, hogy változtassunk a beállításokon. Akkor a leg- 
jobb megoldás, ha sok ugyanolyan gépünk van, és mind- 
egyik ugyanazt a rendszermagot használja — ekkor elég 

a kiszolgálón kicserélni a rendszermag-állományt, s azonnal 
minden gép használni tudja. 


Hogyan tovább? 

Most , hogy ismerjük a GRUB képességeit, fel tudjuk mér- 
ni, hogy mire is van belőle szükségünk. Cikkünk második 
részében megnézzük, hogyan tudjuk telepíteni, használat- 
ba venni és testre szabni; megismerkedünk a menüszer- 
kesztéssel, a héjprogram használatával, s az egyéb hasznos 
beállítási lehetőségekkel. 


Komáromi Zoltán 
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Linuxos kiszolgálót mindenkinek! 49. rész) 


A SuSE Linux, mint kiszolgáló, kisvállalati és otthoni környezetben. 


ikksorozatom eddigi részeiben a Kedves Olvasó 
c megismerkedhetett sok hasznos szolgáltatással, 

amellyel a felhasználóinkat elkényeztettük. Most 
nézzünk egy újabb hasznos szolgáltatást, amellyel a fel- 
használókat fizikai helyüktől függetlenül hálózatba tudjuk 
fogni. Mostani cikkemben a virtuális magánhálózatokkal 
(VPN - Virtual Private Network) foglalkozunk. 


Egy kis elmélet 

A VPN egy olyan szolgáltatás, amellyel bármilyen meglévő 
hálózati infrastruktúra felett saját hálózati környezetet tu- 
dunk kialakítani. Ennek segítségével megtehetjük, hogy 
meglévő hálózatunkat daraboljuk egymástól látszólag 
független hálózati egységekre, de azt is, hogy a felhasználó- 
ink a rendszerben számukra elérhető szolgáltatásokat az 
Interneten keresztül is biztonságos módon vehessék igénybe 
— mintha csak a helyükön ülnének. Ebben az esetben szá- 
mukra teljesen átlátszó módon bekapcsoljuk őket a hálózat- 
ba, így a gépük olyannak fog tűnni, mintha az tényleg a lo- 
kális hálózatban lenne. A megoldás előnye, hogy sokkal biz- 
tonságosabb, mintha a tartalmakat az interneten tennénk 
hozzáférhetővé. Így ugyanis csak az férhet hozzá, aki a VPN 
elérésére jogosult, ráadásul az a megoldás kétirányú elérést 
tesz lehetővé. Tehát nem csak a VPN-en keresztül a hálózat- 
ba lépő felhasználó használhat erőforrásokat, hanem a háló- 
zat tagjai is használhatják az Interneten keresztül VPN-nel 
csatlakozó felhasználók erőforrásait és szolgáltatásait. 


És a gyakorlat 

Ejtsünk pár szót a VPN működésének megvalósításáról. 
Amikor VPN kiszolgálót létesítünk, nem árt ha tisztában va- 
gyunk azzal miként is valósul meg külső gépek bekap- 
csolása a lokális hálózatba. Mivel a VPN-be csatolt külső gé- 
pek potenciális kockázatot jelenthetnek, a tűzfalunk hango- 
lását és a szolgáltatások elérésének korlátozását a VPN mű- 
ködéséhez kell igazítanunk. 

A következőkben tárgyalt megoldások mindegyike úgy mű- 
ködik, hogy a VPN kliensek által elérhető publikus 
kiszolgálóra telepítjük a VPN démont, amelynek feladata, 
hogy a használt kiszolgálótól függően adott kapun várakoz- 
zon és figyelje a kapcsolódó klienseket. 

Amint egy kliens megszólítja a szervert, az valamilyen azo- 
nosítási folyamat után becsatolja a klienst a hálózatba, még- 
pedig úgy, hogy mind a kliens, mind a kiszolgáló oldalán 
megjelenik egy virtuális hálózati csatlakozó, amelyen ke- 
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resztül a kiszolgáló és a kliens bonyolítani tudja a kommu- 
nikációt. Az új csatlakozó megjelenése a rendszerben legke- 
vesebb annyit jelent, hogy a gépek közötti elérések 
biztosításához módosítanunk kell a rendszerek útvonal vá- 
lasztási tábláit (route tables), hiszen a VPN kiszolgáló a LAN 
és a VPN kliens között egy átjárót (gateway) fog jelenteni. 
Ideális esetben ezen az átjárón üzemeltetünk egy tűzfalat 
is, amely a VPN felől érkező klienseket az Internet felől ér- 
kező klienseknél megbízhatóbbnak kezeli, de semmiképpen 
nem biztosít minden olyan jogot, amit egy olyan gép kap- 
hat, amely fizikailag a lokális hálózatban foglal helyet. 
Összefoglalva, a VPN kiszolgáló- és kliensoldalán egy-egy 
új, virtuális hálózati csatoló jelenik meg, amelyek a fizikai 
hálózati csatoló egy adott kapuját használva valósítják meg 
az adatátvitelt. Ezt az egy kapun történő kommunikációt 
nevezik alagutazásnak (tunneling). Az azonban, hogy a két 
VPN fél közötti adatfolyamot egy csatornába 
kényszerítettük még nem biztosíték arra, hogy ez a kom- 
munikációs csatorna megbízható. Ugyan nem kötelező, de 
nagyon ajánlott valamilyen titkosítás használata, ugyanis 
ezzel nagyban megnehezíthetjük az esetleges támadó dol- 
gát. A titkosításra ismertek szimmetrikus és nyílt kulcsú tit- 
kosítási megoldások is. 


VPN megoldások 


Ha úgy döntünk, hogy VPN-re van szükségünk és ezt egy 
Linux kiszolgáló segítségével szeretnénk megvalósítani, ak- 
kor minden bizonnyal leülünk a gép elé és elkezdünk ke- 
resgélni az Interneten. Ha ezt tesszük, akkor biztosak lehe- 
tünk abban, hogy találunk is jó néhány megoldást a problé- 
mára. Viszont ekkor felmerül a következő kérdés: Melyiket 
válasszuk? Nos, ez már nem ilyen egyszerű. Tulajdonkép- 
pen minden megoldásnak vannak előnyei is és hátrányai 
is, így — mielőtt valamelyik megvalósítás üzembe helyezése 
mellett döntünk - nem árt átgondolni, hogy mire is van 
szükségünk tulajdonképpen. 

A VPN-t használhatjuk arra, hogy különböző operációs 
rendszerrel megáldott külső munkaállomásokat kapcsol- 
junk egy hálózatba, úgy, hogy azok csatlakozása a használt 
operációs rendszertől független legyen, és lekezelje azt 

a problémát, hogy a kliens helye, IP címe nagy valószí- 
nűséggel nem állandó - például egy notebook esetében. 
Előfordulhat ugyanakkor az is, hogy nem külső munkaállo- 
másokat szeretnénk becsatolni, hanem több, egymástól füg- 
getlen lokális hálózatot szeretnénk egy nagy virtuális 











hálózattá összekötni, vagy éppen egy nagy lokális hálózatot 
szeretnénk több kis virtuális hálózatra osztani. Utóbbi eset- 
ben nagy valószínűséggel olyan kiszolgálókkal dolgozha- 
tunk, amelyeknek az IP címe állandó és — optimális esetben 
— a gépek operációs rendszere is azonos: esetünkben ilyen 
például valamelyik Linux változat. 

Noha első ránézésre nincs nagy különbség a két említett 
probléma között, azt azért jó tudni, hogy a két összeállításra 
más-más megoldás az optimális. 

Nézzük meg a kínálatot, milyen megoldások állnak rendel- 
kezésünkre. Használhatjuk VPN kialakításához a Poptop 
csomagot, az OpenVPN csomagot, vagy a Freeswan IPSec 
dásokat is, ezek az általam használt és bemutatni kívánt 
rendszerek. 

A Poptop egy Linuxos PPTP kiszolgáló. A PPTP (Point to 
Point Tunneling Protocol) egy Microsoft fejlesztésű VPN 
megoldás, amellyel meglehetősen egyszerűen csatolhatunk 
Windowsos és Linuxos PPTP klienseket a virtuális magán- 
hálózatunkba. Amennyiben könnyen, gyorsan konfigurál- 
ható és egyszerűen használható VPN megoldást keresünk, 
akkor ez nagyon jó megoldás lehet. Különösen jól használ- 
ható olyan környezetben, ahol a VPN kliensek valamilyen 
Windows operációs rendszert futtató gépek. 

A Poptop rendszer egy PPTP protokollt társít a Linux PPP 
kiszolgálójához, így a rendszer a telefonos betárcsázáshoz 
teljesen hasonló módon konfigurálandó. 

A Poptop szerverről bővebben a 5 httpAXAwwww.poptop.org 
címen olvashat az érdeklődő. 

Az OpenVrN egy könnyen használható, SSL támogatást biz- 
tosító VPN démon, amelyhez létezik Linux és Windows ol- 
dali szoftver is, így ez is használható heterogén rendszerek- 
ben. Posix rendszereken való használatnál az OpenVPN cso- 
mag telepítése után létre kell hoznunk a megfelelő virtuális 
hálózati csatlakozókat, amelyeken keresztül a kommunikáció 
folyik majd. Ezután a VPN csatorna két oldalán el kell indíta- 
ni egy parancssoros démont, amelyet a megfelelő paraméte- 
rekkel ellátva felépül a hálózatokat összekötő csatorna. 
Windowsos kliens esetében a projekt weboldaláról letölthe- 
tő telepítőt kell lefuttatni, amely utána a rendszerben 
virtuális csatlakozókat fog létrehozni, amely csatlakozókon 
keresztül tudjuk a VPN erőforrásait elérni. 

Az OpenVrN tartalmaz SSL támogatást, ami annyit jelent, 
hogy a kommunikációs csatorna forgalmát mindkét oldalon 
nyílt kulcsú titkosítási módszerrel titkosítjuk, így a csatorna 
forgalmának lehallgatása gyakorlatilag lehetetlenné válik. 
A módszer hátránya, hogy a kódolás erős gépet, vagy cél- 
eszközt igényel. Az OpenVPN projekt megtalálható az 

5 httoNXwww.openvpn.sourceforge.net weboldalon. 

Az IPSec (Internet Protocol SECurity) egy erős biztonsági 
megoldásokkal ellátott protokoll, amelyet az IETF (Internet 
Engineering Task Force) fejlesztett ki és amely megoldás az 
IPv6-nak már alapszolgáltatása lesz. IPv4-es rendszerünket 
is felkészíthetjük az IPSec támogatására, ha a megfelelő 
rendszermag módosításokat elvégezzük, valamint telepít- 
jük a felhasználói csomagokat. 

A fentiekből is látszik, hogy az IPSec több mint egy VPN 
megoldás: ez egy alacsony szinten megvalósított biztonsági 
megoldás. Az IPSec protokollnak több implementációja lé- 
tezik, ebből az egyik az általam említett Freeswan/IPSec. 
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Emellett léteznek egyéb fejlesztések is, így például a Win- 
dows operációs rendszerek egy a Microsoft által készített 
IPSec megoldást tartalmaznak. Mivel az IPSec hamarosan, 
az IPv6 bevezetésével és széles körű elterjedésével a min- 
dennapok részévé fog válni, ezért érdemes megismerkedni 
vele, érdemes tudni miként működik. 

A Freeswan/IPSec projektről az érdeklődők egy kiterjed 

és nagyon alapos dokumentációt találnak 

a 5 httoAwww.freeswan. org címen. 


Használat a gyakorlatban 

Gyakorlati útmutatónk alkalmával a Poptop és az 
OpenvVrN projektek kínálta megoldásokat tanulmányoz- 
zuk át részletesen. A Suse 9.0-s verziója már tartalmazza 
mindegyik szolgáltatást, ellentétben a 8.2 kiadással, amely 
csak az OpenVPN csomagot tartalmazza. Ettől még nem 
kell megijedni, a projektek weboldaláról minden esetben 
letölthetőek a legfrissebb telepítő készletek, így azok akár- 
melyik Linux kiadáshoz telepíthetőek. 

Suse 9.0 esetén a telepítés meglehetősen egyszerű. A YaST 
csomagtelepítőjében a megszokott módon megkeressük 

a kívánt csomagokat és telepítjük. Innentől kezdve a telepí- 
tett rendszer konfigurálható, használható. 


Poptop kiszolgáló beállítása 

Először nézzük a Poptop PPTP kiszolgáló beállítását. Ehhez 
telepíteni kell a Poptop csomagot, valamint a PPP csoma- 
got, és arendszermaghoz PPP támogatást kell biztosítani. 
Amennyiben a PPP modul le van fordítva, úgy az /etc/ 
modules.conf állományban be kell jegyezni, amennyiben 
nincs a rendszermaghoz PPP támogatás, úgy a támogatás 
bekapcsolásával újat kell fordítanunk. (A Suse által telepí- 
tett rendszermaghoz van PPP modul fordítva, így annak 
fordításával nem kell bajlódnunk. Amennyiben ADSL, vagy 
modemes kapcsolatot használunk, úgy a PPP meghajtó 
minden bizonnyal be van töltve, ugyanis az szükséges az 
előbb említett kapcsolatok kezeléséhez.) 

Miután telepítettük a PPTP kiszolgálót néhány konfiguráci- 
ós állományban módosításokat kell elvégeznünk. Ezen mó- 
dosításokat most a dokumentáció alapján nézzük. 
Amennyiben valamelyik állomány a mi rendszerünkben 
más helyen található, úgy ott az elérési utakat értelemsze- 
rűen módosítani kell. Az első módosítandó állomány a már 
említett /etc/modules.conf. Itt akövetkező modulok 
betöltését kell bejegyezni: 

alias char-major-108 ppp. generic 

tty-Idisc-3 ppp.async 

tty-Idisc-14 ppp. synctty 

ppp-compress-18 ppp. mppe 

ppp-compress-21 bsd comp 


alias 
alias 
alias 
alias 
alias 
alias 
alias 


ppp-compress-24 ppp. deflate 
ppp-compress-26 ppp. deflate 
net-pf-47 ip. gre 


A PPIP démon alapbeállításait az /etc/pptpd.conf állomány- 
ban találjuk meg. Ez az állomány nem tartalmaz túl sok be- 
állítást, mindössze azt mondja meg, hogy a PPP beállítási 
állomány pontosan hol található, valamint egy IP-t ad a ki- 
szolgáló VPN interfészének és egy IP tartományt ad a csat- 
lakozó klienseknek. 
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Egy példa az /etc/pptpd.conf állományra: 
option /etc/ppp/options.pptpd 
ftdebug 

localip 192.168.0.1 

remoteip 192.168.0.200-249 


A fenti konfiguráció azt mondja, hogy a PPTP démon PPP ál- 
lománya az /etc/ppp könyvtárban az options.pptpd állomány- 
ban van, a kiszolgáló a 192.168.0.1-es címet kapja és a kliensek 
a 192.168.0.200 és a fölötte lévő 50 címből gazdálkodhatnak. 
A debug kapcsoló bekapcsolásával elérhetjük, hogy a démon 
teleírja a naplót a futási állapot üzeneteivel, így adva egy 
nagyszerű eszközt az esetleges hibák elhárításához. 

A pptpd.conf állományban megnevezett PPP konfigurációs 
állományt az alábbi tartalommal lássuk el: 

lock 

tdebug 

name pptpd 

nobsdcomp 

proxyarp 

ms-wins chálózati-wins-kiszolgáló-ip-címez 

ms-dns chálózati-dns-kiszolgáló-ip-címez 


Ezzel a beállítással egy titkosítás nélküli VPN csatornát léte- 
sítünk, ami ugyan működő megoldás, de nem egy biztonsá- 
gos összeállítás. A Poptop PPTP kiszolgáló ellátható SSL 
titkosítással is, amennyiben a kiszolgálóhoz tartozó MPPE 
foltot is telepítjük. A foltozás letölthető a Poptop projekt 
weboldaláról is. Amennyiben telepítettük az MPPE és 
ChapMS kiegészítést, úgy az alábbi sorokat hozzáadva az 
options.pptpd állományhoz elérhetővé tehetjük a Windows 
kliensek által is titkosítást: 

-chap 

-chapms 

3chapms-v2 

mppe-40 

mppe-128 

mppe-stateless 


A fenti szolgáltatások elérhetőségét, szükségességét az aláb- 
bi sorok értelemszerű beszúrásával állíthatjuk: 
frefuse-pap 

ftrefuse-chap 

frefuse-mschap 

$reguire-mschap-v2 

freguire-mppe 


Ha végeztünk az options.pptpd állománnyal, akkor az 
letc/ppp/chap-secrets állományban megadhatjuk, hogy me- 
lyik felhasználó milyen jelszóval milyen gépről érje el 

a szolgáltatást. Ehhez mindössze egy sort kell felhasználón- 
ként beszúrni, ami a következőképpen néz ki: 

felhasználó neve pptpd "jelszó" cIP tartományz 


Pédául: 
viktor pptpd "passwd" 192.168.0.100 


Ezzel a viktor nevű felhasználó a passwd jelszóval 
a 192.168.0.100-as című gépről tud bejelentkezni. Amennyi- 
ben az IP cím helyére "-ot teszünk, akkor az az IP korláto- 
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zás teljes feloldását jelenti. Ha ezzel végeztünk, akkor nincs 
is más dolgunk, mint újraindítani a pptp kiszolgálót és már 
csatlakozhatunk is a géphez. Amennyiben a PPTP kiszolgá- 
ló tűzfallal védett, ne felejtsük el engedélyezni a 1723-as 
TPC és UDP portot. A Poptop kiszolgáló teljes dokumentáci- 
ója és további érdekes és hasznos információk megtalálható- 
ak a projekt honlapján. 


Az OpenVPNI projekt 

Az OpenVEN kiszolgáló telepítéséhez a YaST csomagtelepí- 
tőjével az openupn csomagot kell telepítenünk. Ezután az 
/usr/sbin könyvtárban megjelenik az openvupn nevű tuttat- 
ható állomány. OpenVPN esetén alapesetben ezen az állo- 
mányon kívül nem is lesz szükségünk semmilyen más kon- 
figuráció elkészítésére, parancssorból paraméterezve tudjuk 
futtatni a kiszolgálót. Ez előtt azonban kell még tennünk 
egy-két előkészületi lépést. Amennyiben 2.4.7-esnél frissebb 
rendszermagot használunk - ami egyébként elég valószínű 
—, akkor telepítenünk kell a TUN/TAP meghajtót. Ha ez 
megvan, akkor létre kell hoznunk a /dev/net/tun nevű esz- 
közt az alábbi paranccsal mknod /dev/net/tun c 10 200, 
majd töltsük be a meghajtót a modprobe tun parancs futta- 
tásával. Ha rpm csomagból telepítjük a programot, akkor az 
eszköz létrehozására nincs szükség, mert ezt a telepítő el- 
végzi. Amennyiben a kiszolgálón tűzfal fut, úgy ne feled- 
kezzünk meg a tűzfalon a tun eszköz megfelelő beállításá- 
ról sem! Ha a fentiekkel mind elkészültünk, akkor jöhet 
amire vártunk, indíthatjuk a kapcsolatot. Ez, mint már emlí- 
tettük, parancssorból történik. Íme egy séma egy egyszerű, 
titkosítás nélküli VPN csatorna létrehozására: 

openvpn --remote cellenoldali-gép-hostnevez --dev 
stun1 --ifconfig chelyi-tun-csatoló-IP-címes 

5 ctávoli-tun-csatoló-IP-címez 


Nézzünk egy példát. Van két helyi hálózatunk, ahol az 
egyik hálózat átjárójának címe gw1.hu, míg a másik hálózat 
átjárójának címe gw2.hu, valamint a gw1.hu gépen 
10.1.1.100 címet adunk a tun1 hálózati csatolónak, míg 
gw2.hu gépen 10.1.1.200-at. Ezután a gw1 gépen az alábbi 
parancsot kell futtatni: 

openvpn --remote gw2.hu --dev tunl --ifconfig 
"5510.1.1.100 10.1.1.200 


A másik, tehát gw2.hu gépen pedig a következő paranccsal 
építhető ki a kapcsolat: 

openvpn --remote gwl.hu --dev tunl --ifconfig 
"510.1.1.200 10.1.1.100 


Mint látható a kapcsolat felépítése rendkívül egyszerű. Ter- 
mészetesen lehetőségünk van arra, hogy titkosított csator- 
nát használjunk a kommunikáció során. Az OpenVPrN tá- 
mogat mind szimmetrikus, mind TLS alapú titkosítási mód- 
szereket, így mindenki választhat igényének megfelelően. 
Azok, akinek az érdeklődét sikerült felkelteni a VPN iránt, 
bőséges olvasnivalót találnak a témában a projektek hon- 
lapjain. Ezzel a cikkel a Suse Linux-ról szóló cikksorozatom 
végére értünk. Remélem sikerült kedvet csinálnom, nem- 
csak a Suse, de akármelyik Linux kiadás megismeréséhez. 


Illés Viktor 











A GIMP eszközkészlete 


Sorozatunk aktuális részében megismerkedhetünk a GIMP bőséges eszköz- 
tárának további tagjaival és azok különféle beállítási lehetőségeivel. Ezek után 
két egyszerű példán keresztül bemutatom, hogy ezek az egyszerű eszközök, 

a megfelelő sorrendben alkalmazva milyen hatékony munkát tesznek lehetővé. 


z 1-es képen láthatjuk a program alapértelmezett 
A eszközkészletét. Most csak azért került ide a kép, 

hogy olvasás közben ne kelljen ide-oda tekintget- 
ve az olvasottak felét a monitorról, másik felét a papírról 
megérteni. 
Minden eszköz esetében az eszközre jellemző tulajdonsá- 
gokat elérhetjük és beállíthatjuk, ha az adott gombra dup- 
lán kattintunk a bal egérgombbal. 
A kiválasztásra szolgáló eszközökkel már megismerkedtünk 
az első részben, így most folytassuk a sort a nagyítóval. Már 
erről is esett némi szó, de érdemes megjegyezni, hogy a na- 
gyítás nem csak pozitív előjelű lehet. A CTRL billentyű le- 
nyomása mellett a képre kattintva, a nagyítás helyett kicsi- 
nyítést hajthatunk végre a GIMPben. Az eszköz beállításai 
között találhatunk egy bekapcsolható mezőt, amivel meg- 
határozhatjuk, hogy a nagyítás során a program átméretez- 
heti-e az ablakot. 
A következő eszköz az ikonja alapján leginkább sziké- 
hez hasonlítható. Nem meglepő a hasonlóság, ugyanis 
valóban egy vágásra használható eszközről van szó. A kép- 
ből tetszőleges, téglalap alakú részeket vághatunk ki a segít- 
ségével. 
Nagyon nagy hasznát vehetjük ennek a funkciónak akkor, 
amikor például kicsit ferdén olvastunk be egy képet a lapol- 
vasóval, ferdén tartottuk a digitális fényképezőgépünket 
vagy csak egyszerűen a lényeget szeretnénk kiemelni egy 
képből. Ilyenkor jelöljük ki a vágóeszközzel a kívánt részt. 
Ekkor megjelenik egy párbeszédablak, ahol pontosan beál- 
líthatjuk a kezdőpontokat és a méretet, majd a Crop gomb 
hatására a program kivágja a szükséges darabot. A méretet 
és a kezdőpontot a képen megjelenő kerettel is igényeink- 
nek megfelelően változtathatjuk. 
Fontos lehet megismerkedni a tükrözésre használható esz- 
közzel, amit a kétfelé mutató nyíl ikon jelez. Alapállapotban 
a képet a függőleges tengelye körül fordítja el 180 fokkal, 
ha azonban lenyomjuk a CTRL gombot az egérgombbal 
együtt, akkor a program a vízszintes tengelyt veszi alapul. 
Már egy példába segítségével is láthatjuk, hogy mire lehet 
használni ezt az egyszerű megoldást. Aki olvasta a Blender 
sorozatot, annak rögtön eszébe juthat, hogy annak idején 
tengelyesen tükrözhető tárgyakat készítettünk, és azoknak 
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1. kép A GIMP eszközkészlete 


csak egyik felét kellett modellezni. A GIMP-ben sincs ez 
másként, gondoljunk csak egy szívre, egy vázára, virágra 
vagy akár egy ablak megrajzolására. 


Szövegeljünk egy kicsit! 

Felmerülhet a kérdés, hogy hogyan lehetne a GIMP segítsé- 
gével megtervezni a cégfeliratunkat. Hogyan lehet magya- 
rázó szöveget készíteni az oktatási anyagunkban szereplő 
képekhez? Egyáltalán lehet szöveget használ a GIMP-ben? 
Nos, a választ a "T" betűt formázó gomb használatával kap- 
hatjuk meg. Ha ezt a gombot választjuk, akkor az egérmu- 
tató átalakul a szövegszerkesztőkben használatos "T formá- 
jú mutatóvá és a képen kijelölhetjük a szöveg helyét. A szö- 
veghelyzet megadása után egy betűtípust kell választa- 
nunk, ezt követően pedig a párbeszédablak alsó részén lévő 
mezőbe beírni a kívánt szöveget, ami rögtön a kiválasztott 
típussal jelenik meg, tehát tetszőlegesen válogathatunk, 
hogy megtaláljuk az igényeinknek megfelelő betűtípust. 
Ezután az OK gomb hatására a program elhelyezi a meg- 
adott helyen a szöveget és az kijelölt állapotban marad. 
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Ekkor még van arra lehetőségünk, hogy pontosítsuk a hely- 
zetét, vagy új réteget hozzunk létre és arra helyezzük el. 


Ha túl sok a szemét... 

Milyen lehetőségeink vannak, ha egy képen bizonyos javí- 
tásokat szeretnénk elvégezni? Ez több dologtól is függ. Ha 
például a javítandó területen hasonló mintázatok vannak 
(például szemét volt a park füvén és arra nincs szükség 

a képen), akkor használhatjuk a környező képrészleteket, 
és azokkal fedhetjük le a kívánt területet. Van azonban 

a képterületek másolásának másik módja is, amelyet majd 
a későbbiek során ismertetünk. 

No de mi történjen akkor, ha nem hasonlók ezek a részle- 
tek, és kénytelenek lennénk képpontonként változtatni 

a színeket. Erre adhat megoldást a pipetta eszköz. Amikor 
ezt kiválasztjuk, és a képen egy pontra kattintunk, a GIMP 
megjelenít egy ablakot, amelyben többféleképpen is olvas- 
hatjuk a választott pont színét. Az 1-es képen látható ez 

a párbeszédablak is. Fontos megjegyezni, hogy a pipetta 
használatakor az aktuális rajzolószín is megváltozik. Másik 
előnye ennek az eszköznek, hogy amikor weblapot készí- 
tünk, az átlátszó képek helyett használhatunk háttérrel ren- 
delkezőeket, és a GIMP tizenhatos számrendszerben (aho- 
gyan a HTML oldalakban szükséges) is kiírja a választott 
színt. Ennek alapján már könnyen beállíthatjuk a HTML ol- 
dal háttérszínét. A szükséges formában a Hex Triplet sorban 
látható a szín meghatározása. 

Különös figyelmet érdemel a GIMP területkitöltő eszköze. 
Az ikonja leginkább egy festékes vödörhöz hasonlít. Alap- 
vető működése szerint az éppen aktuális rajzolószínnel ki- 
tölti azt a területet, ahol lenyomjuk a bal egérgombot. 


Fessük is ki... 

Talán még nem szóltam arról, hogy hogyan lehet a GIMP- 
ben kiválasztani a használni kívánt színeket. Az eszköztá- 
ron látható két színes lapocska, aminek egy-egy sarka egy 
nyíllal van összekötve. Nos, mindkét lapocska az éppen 
használatban lévő színekre vonatkozik. Az előrébb lévő az 
előtérszín vagy rajzolószín, míg mögötte a háttérszín lát- 
szik. Az őket összekötő nyíl arra szolgál, hogy ezt a két 
színt felcseréljük. 

Ha valami miatt meg szeretnénk változtatni valamelyik 
színt, akkor dupla kattintásra előbukkan egy párbeszédab- 
lak. Itt többféleképpen is megadhatjuk az új színt, hasz- 
nálhatunk RGB értékeket, HSV értékeket és többfajta pa- 
lettából az egérrel használatával is választhatunk. Ezek 

a beállítások a háttérszínére éppúgy alkalmazhatók, mint 
a rajzolószínre. Tehát a területkitöltés alkalmazható a meg- 
szokott módon, viszont a CTRL gomb lenyomása mellett 

a program a háttérszínt használja a színezéshez. További 
beállítási lehetőségekhez juthatunk ha kettőt kattintunk az 
eszköz gombján. Megadható az érzékenység, vagyis az, 
hogy az egérmutató alatt lévő képpont színéhez képest mi- 
lyen mértékben vegye figyelembe a program a hasonló szí- 
neket. Például ha valamilyen árnyalást használtunk, akkor 
az alapértelmezett kitöltés szerint a halványabb részeket 
nem tudjuk befesteni a festővödör használatával. Ilyenkor 
az érzékenységet magasabbra állítjuk, majd megismételjük 
a műveletet és a GIMP ekkor már az elhalványuló körvona- 
lakat is kitölti a megfelelő színnel. 
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2.kép A készülő logo 


Természetesen nem csak egyszerű színekkel festhetünk, 
hanem alkalmazható az éppen aktuális kitöltő minta is. 
Ennek kiválasztása úgy történhet, hogy az eszköztárban, 

a színpaletta melletti mintázatra kettőt kattintunk, majd 

a megjelenő párbeszédablakból, kiválasztunk egy tetszőle- 
ges mintázatot. 

A következő eszközünk az átmenetek festésére szolgál és 
könnyen felismerhető az ikonja alapján. A GIMP-ben tet- 
szőleges színátmenetet létrehozhatunk vagy a meglévőket 
is átalakíthatjuk. Kattintsunk duplán az eszköztárban az ak- 
tuális színeket mutató paletta mellett a színátmenetre. Szin- 
tén egy párbeszédablakból választhatjuk ki a beépített át- 
menetek egyikét, majd az Edit gomb segítségével igénye- 
inknek megfelelően szerkeszthetjük. 

Ha megelégszünk az egyszerűbb átmentekkel is, akkor 

a színátmenetfestő eszköz beállításainál választhatunk elő- 
térből-háttérbe vagy háttérből-előtérbe tartó átmenetet. Itt 
adhatjuk meg azt is, hogy milyen formát kövessen a színát- 
menetes festés. A GIMP-ben többféle típust találunk, példá- 
ul egyszerű vonalmenti átmentet (Linear), gömbszerű átme- 
netet (Spherical), kúpszerű átmenetet (Conical), a kijelö- 

lés formájához igazodó átmenetet (Shapeburst) és spirál 
alakú átmenetet (Spiral). Mindezeket a beállítások ablaká- 
ban a Gradtent felirat melletti legördülő listából tudjuk 
kiválasztani. 


Gyakorlat teszi... 

Készítsünk most egy egyszerű feliratot, aminek a körvona- 
lát kiemeljük más színnel. A felirat maga színátmenettel le- 
gyen kitöltve, és ne feledkezzünk meg a betűk belső részé- 
nek kiemeléséről sem. 

Készítsük el a feliratot a szöveges eszközzel és helyezzük el 
a kívánt helyre. Ezután a CTRL-L billentyűkkel jelenítsük 
meg a rétegek kezelésére szolgáló ablakot és az első gombra 
kattintva hozzunk létre új réteget. A létrehozott rétegen 
szín szerinti kiválasztással (Kép menüje- - Selection- - Select 
by color...) jelöljük ki a szöveget ismét. Most következhet az 
átmenetes kitöltés. Ezután növeljük meg a kijelölt területet 
a kívánt mértékben (1-2 pixel) a Kép menüje- - Selection-- 
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3. kép Különféle keresztmetszetek 


Grow menüpontok segítségével, majd hozzunk létre még 
egy új réteget. Ezt területet fessük ki olyan színnel, amivel 
a körvonal kiemelését szeretnénk viszontlátni. Az eddigi lé- 
pések alapján látható, hogy az átmenettel kitöltött felirat el- 
tűnt, hiszen a körvonal kiemelésére szolgáló réteg eltakarja. 
A rétegek párbeszédablakában nyomjuk megg a lefelé muta- 
tó nyíllal jelzett gombot, így máris elértük a kívánt ered- 
ményt. Láthatjuk első átmenettel rendelkező, kiemelt kör- 
vonalakkal megjelenő feliratunkat. A 2-es képen a fenti lé- 
pések követhetők nyomon. 

Fontos, hogy jól látható legyen. Pl. Két hasábra vagy hason- 
ló. Ha nem oldható meg, akkor nem kell a kép és az előző 
bekezdés utolsó mondata sem. 

Szabadkézi rajzoláshoz is többféle eszköz áll rendelkezé- 
sünkre. Az egyik a ceruza, ami kevesebb beállítási lehető- 
séggel főként egyszerű vonalas ábrák készítésére használ- 
ható. Mindkét eszköz esetében érvényes, hogy ha a SHIFT 
billentyűt lenyomva tartjuk, akkor az utolsó pozícióból in- 
dulva egyenes vonalat húzhatunk. Utolsó pozíciónak az 

a képpont számít, ahol a vonalrajzolás előtt utoljára le- 
nyomtuk a bal egérgombot. A rajzeszköz keresztmetszetét, 
vagyis a rajzolt alakzat formáját szintén az eszköztár alsó 
részén állíthatjuk be. A mintázatok gombja mellett található 
egy újabb gomb, amit alkalmazva (meglepő módon) egy 
párbeszédablakhoz jutunk. Ez látható a 3-as képen (néhány 
mintával, melyek a ceruza eszközzel készültek), és innen 
tudjuk kiválasztani megfelelő formát. 

A másik, szabadkézi rajzhoz használható eszköz az ecset. 
Szintén különféle keresztmetszetű darabokat használha- 
tunk, azonban egy lényeges különbséget felfedezhetünk 

az ecset és a ceruza között. Az ecset alkalmazásakor az 
olyan formák, amiknek a széle elhalványul, valóban halvá- 
nyabb képet eredményeznek. Ez talán annak tudható be, 
hogy az ecsetek nem egységesen érintkeznek a vászonnal 
vagy papírral. 

Köztudott az is, hogy az ecsetből hamarabb fogy ki a festék, 
mint ahogy egy ceruza elfogyna. A GIMP-ben ennek a fes- 
tékfogyásnak is megvan a megfelelője. Az ecset beállításai 
között megadható a Fade érték, ami ezt a fogyást kívánja 
szimulálni. A másik érdekesség, hogy színátmenetes ecset- 
vonásokat is rajzolhatunk. A Gradtient feliratnál beállítható, 
hogy milyen hosszú legyen egy-egy átmenet és a típus 
megadása után már rajzolhatunk is a szép ecsetvonásokkal. 
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Négyféle beépített típust találunk. A felső kettőt talán nem 
kell magyarázni. A harmadik, a fűrészfog-szerű ismétlés 
(Loop sawtooth), tulajdonképpen azt jelenti, hogy az átme- 
net végén a következő szín a színátmenet elején található 
lesz. A háromszög (Loop triangle) formájú átmenet esetén 
az utolsó szín elérésekor visszafelé jönnek a színek. Az el- 
nevezéseket könnyebben megérthetjük, ha elképzeljük 

a háromszöget és a fűrészfogat. Ekkor a vízszintes tengely 
az idő-tengely, a függőleges pedig a színátmenet aktuális 
színének helyzete a teljes átmenetben. 

Talán feltűnt a kedves olvasók egy részének, hogy ez utóbbi 
két eszköznél (és majd továbbiaknál is) a beállítások között 
találhatunk egy bizonyos Pressure Sensitivity feliratot. 

A GIMP képes kezelni a rajzolótáblák nyomásérzékenysé- 
gét, és ezt a kiegészítő információt különféle módon hasz- 
nálhatjuk fel. Változtathatjuk vele a színek átlátszóságát 
(Opacity), az eszköz rajzolatának erősségét (Hardness, 
Rate), a méretét (Size) vagy a színátmenet éppen alkalma- 
zott színét (Color). Természetesen ennek a lehetőségnek 

a használatához, olyan táblát kell használni, amit az 
XWindow rendszer is felismer és bemeneti eszközként ke- 
zelni képes. Ilyenek például a Wacom Intuos és a Graphire 
táblák, amelyek a Wacom IV és a Wacom V protokollt hasz- 
nálják. Jelenleg néhány Linux változatban található támo- 
gatás az USB kapun csatlakozó eszközökhöz is. 

Nem lehetne teljes értékű pixelgrafikus rajzolóprogram 

a GIME ha nem találnánk benne lehetőséget a változtatások 
visszavonására. Az egyik ilyen megoldás a szokásos visszavo- 
nás művelet, melyet a CTRL-Z billentyűvel érhetünk el. 

A visszavonható lépések számát beállíthatjuk a már tárgyalt 
általános beállítások párbeszédablakban. Emlékeztetőül, ez az 
érték elérhető az Eszköztár ablaka-: File menü-: Preferences 
menüpont-: Environment-: Levels of undo beállításán ke- 
resztül. 

A másik lehetőség, a radír használata. Szintén könnyen fel- 
ismerhető az eszköztárban, ikonja hasonlít egy szokásos ra- 
dírhoz. Amikor használjuk, azt fogjuk látni, hogy az éppen 
aktuális rajzoló formával radírozhatunk, és a kiradírozott 
területek háttérszínnel jelennek meg. Beállításai között ta- 
lálhatunk egy Hard edge nevű lehetőséget, amellyel a radír- 
nak a formától függetlenül éles szélei lesznek. Például, ha 
elmosott szélekkel rendelkező formát használunk, de ezt 

a lehetőséget beállítjuk, akkor a halványodó körvonalakat 
a program figyelmen kívül hagyja. Így egészen pontos mű- 
veleteket végezhetünk, például egy beolvasott vonalas raj- 
zon vékonyíthatjuk a vonalakat vagy teljesen kitörölhetjük 
a felesleges részeket. 

Az ilyen lapolvasóval beolvasott vonalas rajzok esetén elő- 
fordulhat, hogy a ceruzával készült rajzot egy kicsit elma- 
szatoltuk rajzolás közben. Ez a papíron nem olyan feltűnő, 
nem is zavaró, mégis akadályozhatja a további számítógé- 
pes feldolgozást. A lapolvasó ugyanis az ilyen alig látható 
maszatokat is képes megkülönböztetni a fehér papírtól, és 
annak rendje és módja szerint be is digitalizálja őket. A kép 
használhatóvá tétele a számítógép feladata lesz, erre lás- 
sunk most egy egyszerű megoldást. 

Először próbáljuk a kontraszt növelésével eltüntetni a ma- 
szatokat. Ezzel a megoldással már jó eredményt érhetünk 
el, de előfordul, hogy még mindig maradnak felesleges fol- 
tok. A következő lépés legyen a szín szerinti kiválasztás. 
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4. kép lgazított és nem igazított mintázat 


Válaszuk ki alacsony tűréssel a nem kívánt színeket és 

a CTRL-K billentyűkkel töröljük ki azokat. A tűrés változta- 
tásával próbáljunk minél több felesleges színt kiválasztani, 
de vigyázzunk, hogy a fontos részeket ne töröljük ki. Most 
már lehet, hogy olyan vonalakból is eltűnt néhány képpont, 
amik szándékunk szerint folyamatos vonalak lettek volna. 
A folyamatos vonal és a körbezárt területek rendkívül fon- 
tosak a kifestés szempontjából. 

A vonalak folytonosságának visszaállítására használhat- 
juk újra a szín szerinti kijelölést, most azonban azokat a szí- 
neket válasszuk ki, amelyeket látni szeretnénk a vonalak 
színeként. Növeljük meg a kijelölést, majd a kijelölt terüle- 
teket fessük ki egy színnel. Így visszaállíthatjuk a vonalak 
folyamatosságát. 

A vastag vonalak vékonyítására megoldás lehet, ha 

újra kijelöljük a kívánt vonalszínt a szín szerinti kivá- 
lasztással és ezután csökkentjük a kiválasztott terület 
méretét a Kép menü- : Select-- Shrink... menüpontok 
választásával. 

Ezzel skeresen kiválasztottuk a megfelelő területeket. 
Invertáljuk a kijelölést a CTRL-I billentyűkkel, és fessük 

be újra — de most már a háttérszínnel -— a kiválasztott 
területet. 

Ilyen és ehhez hasonló lépésekkel alakíthatjuk át a beol- 
vasott vonalas rajzot további feldolgozási (pl. színezés, ár- 
nyalás, különféle hatások hozzáadása) céljainknak megfe- 
lelően. Ha maradt felesleges rész, azokat kis munkával 
kiradírozhatjuk. 

Ha már így belejöttünk a képfeldolgozásba, gondoljuk át, 
hogyan készíthetnénk a beolvasott vonalas rajzból, árnyalt 
képet. Bizonyára lesznek a rajzon olyan területek, amiket 
egyszínűre festhetünk. Ezekkel nem lehet gond. A színát- 
menetek alkalmazása is megkönnyíti a munkát, a jól meg- 
választott átmenet-típusokkal és irányokkal látványos ered- 
ményeket érhetünk el. 

Előfordulhat, hogy bonyolultabb felület árnyalását szeret- 
nénk elvégezni a programmal. Például, ha egy átmenetre 
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szeretnénk mintákat festeni, készíthetjük azt egy másik 
rétegen, és az átlátszóság szabályozásával meghatározhat- 
juk a mintázat hatásának mértékét. A másik megoldás le- 
het, ha a festékszóró (airbrush) eszközt használjuk, finom 
átmeneteket hozhatunk létre egy nagyobb területen is. 

Az eszköznek két érdekes beállítása van. Az egyik a nyo- 
más, a másik pedig a Rate nevet viseli, amit leginkább úgy 
képzelhetünk el, mintha egy valódi festékszórón változtat- 
nánk a szórófej méretét. 

A változtatás hatására a festék gyorsabban áramlik, hama- 
rabb látható a színezés eredménye. A valódi megoldáshoz 
hasonlóan ha egy területen többször haladunk át az esz- 
közzel, akkor több festék kerül a vászonra, tehát a szín is 
sötétebb lesz. 

A GIMP lehetőséget ad képrészletek egyszerű másolására 
is, mégpedig a nyomda eszköz segítségével. Szintén nagyon 
könnyel felismerhető az ikon alapján, tehát bizonyára min- 
denki könnyedén megtalálja az eszköztárban. Kétfélekép- 
pen használható, mindkét esetben a megjelenő lenyomat 
formája a beállított rajzeszköz keresztmetszet formájával 
egyezik meg. Az alapbeállítás szerint a kép egy részletét 
másolhatjuk más helyekre. Az Atr billentyű lenyomva tar- 
tása mellett egérkattintással tudjuk kiválasztani a forráste- 
rületet, majd a billentyű felengedése után másolhatjuk a te- 
rületet. Itt figyelni kell arra, hogy amikor lenyomjuk ismét 
a bal egérgombot, akkor a forrásterületet is elmozdul még- 
pedig az éppen érvényes helyet fogja követni. A forrás- és 
a célterület koordinátái közötti távolság állandó, egészen 
addig érvényes, amíg újabb forrásterületet nem adunk meg 
a programnak. 

A másik használati mód, amikor az érvényben lévő mintá- 
val a valóságnak megfelelően nyomtassunk kis képeket. Az 
eszköz beállításait tartalmazó párbeszédablakban válasszuk 
a Pattern source lehetőséget és máris nyomtathatjuk a min- 
tázatokat a vászonra. Természetesen a mintázatot meg is 
változtathatjuk munka közben. 

További beállítási lehetőségek az igazításra vonatkoz- 

nak. Amennyiben az Aligned pontot választjuk, akkor 

a többszöri rajzolás során (két művelet közben felenged- 
jük az egérgombot), a mintázat folytatólagosan kerül 

a képre, észre sem vesszük, hogy több részletben festettük 
ki a területet. 

A Non Aligned ,igazítás" kiválasztásakor a mintázat bal fel- 
ső sarka az egérgomb lenyomáskor érvényes helyre kerül 

a képen. A különbséget jobban észrevehetjük, ha mindeze- 
ket ki is próbáljuk a gyakorlatban vagy megnézzük a né- 
gyes képen. 

Most már rendelkezünk annyi tudással, hogy szebbnél- 
szebb képeket, logókat vagy akár prospektusokat készít- 
sünk. A megfelelő háttér kiválasztása után már csak a ki- 
sebb képeket kell elhelyeznünk a képen, a feliratokat elké- 
szítenünk és akár saját honlapunkat, akár más nyomtatásra 
szánt cégbemutatónkat saját erőből örömmel megtervezhet- 
jük és elkészíthetjük. 

Mindenkinek kellemes alkotást és tanulást kívánok, a nagy 
nyári melegben nem mindig egészséges a napon sülni, és 
GIMP ismeretek mélyítésének is legalább annyi hasznát lát- 
juk, mint a D-vitaminnak. 


Fábián Zoltán 











A Magyar Linux: UHU 


Gyorsítsunk! 


Linux rugalmasságának rengeteg előnye van. 

Azt mindenki tudja, hogy kisebb-nagyobb műtéttel 

szinte bármilyen eszköz beleilleszthető a rendszer- 
be, de ez csak a legismertebb tulajdonsága. A rendszer hango- 
lásáról viszonylag kevesebb szó esik, holott remekül felgyor- 
sítható, ami eléggé komoly lépés a rendszer testreszabásában. 
Ebben a kis leírásban olyan rendszergyorsító tényezőkre 
próbálunk kitérni, amely a kezdők számára is könnyen vég- 
rehajtható. Nem igényelnek nagy szakértelmet, és nem kell 
nagyon bonyolult műveleteket végrehajtani hozzájuk. Per- 
sze az óvatosság nem árt. Hisz nem egyszer rendesen bele- 
mászunk majd a rendszer lelkivilágába. Azt se felejtsük el, 
hogy minden itt leírt tényező csak kis pluszt szolgáltat egy- 
magában, viszont ha egyszerre többet alkalmazunk már 
szemmel látható a gyorsulás. Ez némileg módosítani fogja 
az UHU-Linux alapértelmezett beállításait figyelembe vett 
hardver igény adatokat. Értelemszerűen csodákra most sem 
leszünk képesek (többszörös növekedést senki ne várjon) 
viszont saját , sufni" méréseim szerint 5090-al biztosan fel- 
gyorsítható a rendszer. 


A rendszer betöltődése 

Az alapbeállításokkal rendelkező UHU-Linux pár olyan dol- 
got is betölt, amelyre az egyéni felhasználónak semmi szük- 
sége. Mindössze azért van beállítva, mert valakinek bizto- 
san jól jönnek. Példának okáért a firewire csatoló moduljá- 
nak betöltése a felhasználók komoly hányadának felesleges. 
Ott van aztán az ISA támogatás, ami új gépeknél szintén fe- 
lesleges lehet. Ha jobban megnézzük az UHU-Linux boot 
képernyőjét, akkor láthatjuk, hogy megkeresi a gépben lévő 
eszközöket, és működésre bírja őket. 

És eközben megpróbál megtalálni olyan eszközöket is, 
amellyel nem rendelkezünk. Ezeket természetesen nem 
fogja megtalálni, a moduljaikat sem fogja betölteni, viszont 
fölöslegesen szöszmötöl a keresésével. Sok időt spórolha- 
tunk meg azzal, ha ezeket nem keresi. Az UHU-Linux ezt 

a műveletet is a szkriptekben leírt módon végzi el. Ezen 
szkriptek az /etc/rc.boot könyvtárban találhatóak. Itt több 
szkript található, sorrendbe rendezve. A fájlok közül néme- 
lyikkel nem érdemes foglalkozni, hisz olyan alapvető hívá- 
sokat tartalmaz, amelyek nélkülözhetetlenek. Ezeknek 

a módosítása súlyos rendszerhibát idézhet elő. Ilyen fájl 

a ,10-boot,15-boot,18-clock,20-urandom" . Ezek a fájlok rá- 
adásul rövidek, elhanyagolható növekedés érhető el a kiikta- 
tásukkal, egyszóval nem éri meg a kockázatot a módosítása. 
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Nem így a 12-detect. A boot folyamat során a képernyőn 
lefutó utasítások 807-át itt találjuk leírva. Ennek a fájlnak 

a módosítása viszont szemmel látható módon rövidíti meg 
a rendszer betöltődését. Szerkesszük hát meg. 
Jelentkezzünk be a su-val konzolon, majd indítsuk el 

a Midnight Commander-t, ami (mint már annyiszor tapasz- 
talhattuk) egy kiváló, gyors, és kényelmes eszköz az ilyen 
műveletek elvégzésére. 

Lépjünk be vele az /etc/rc.boot könyvtárba, és menjünk rá 

a 12-detect fájlra. Ezután üssünk egy sima F4-et, hogy meg- 
nyissuk szerkesztésre. Ha vetünk egy pillantást a fájl tartal- 
mára, rögtön látjuk, hogy egy konkrét szkriptről van szó. 
Ennek fényében tudjuk, hogy nem kell törölni a sorokat, 
hanem elégséges, ha a nem kívánt sor elé rakunk egy tt - 
jelet. Ezzel komment jelzést adtunk egy sornak, tehát közöl- 
tük a rendszerrel, hogy ezt ne vegye figyelembe, ez mind- 
össze egy olyan sor, amit magunknak írtunk. Ezután a jövő- 
ben az adott sort nem fogja figyelembe venni, tehát , hatá- 
lyon kívül" helyeztük azt. 

Általános recept nincsen arra nézve, hogy milyen opciókat 
hagyjon ki a rendszer a betöltődéskor, azonban pár szem- 
pont mindenképpen megemlítendő. Figyeljünk arra, hogy 
olyan utasítást még véletlenül se vegyünk ki, amely általá- 
nos, és minden gépnél szükséges. Ilyen a , PCI eszközök ke- 
resése" . Erre feltétlenül szükségünk van, még akkor is ha 
integrált alaplappal rendelkezünk, és egyetlen PCI-os kár- 
tya sincsen a gépben. Ugyanis az alaplapra integrált egysé- 
gek is egy PCI sinen csatlakoznak egymáshoz. 

Ott van viszont az ISDN: ") - - ; ; közötti rész. Ez nyugod- 
tan kivehető, ha nincs ISDN hálózatunk, és ISDN kártyánk. 
Amennyiben szeretnénk használni, az USB modulokra is 
szükség van. Ha nincsen semmilyen ISA csatolójú eszkö- 
zünk, (figyelem, itt is vegyük figyelembe az alaplap egysé- 
geit! Erről az alaplap kézikönyve tud minket alaposan tájé- 
koztatni.) akkor az ISA eszközök keresése. . . részt is nyu- 
godtan hatástalaníthatjuk. 

Érdekes még a További modulok betöltése. . . rész, mert el- 
képzelhető, hogy innen valamire van, valamire pedig nincs 
szükség. Rögtön a probemod ide-scsi sorral kezdődik. Erre 
mindenképpen szükségünk van. Ez ugyanis a SCSi emulációt 
hívja meg, amelyre a CD-ROM, (nem annyira) vagy a CD- 
RW eszközöknél van (nagyon!) szükség. Amennyiben ezt ki- 
vesszük, gondjaink lehetnek a CD eszközzel, és/vagy használ- 
hatatlanná válik a CD-RW eszközünk. Tehát megtartása mele- 
gen ajánlott. Nem úgy a probemod serial, és a probemod 1p 
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soroké. Az első a soros port, a második a párhuzamos (nyom- 
tató) port. Mindenki döntse el, hogy használja-e ezeket az 
eszközöket, merthogy korántsem biztos az USB-s nyomtatók, 
és PS2 egerek korában. (Ha külső modemet használunk, ak- 
kor az valószínűleg a soros portra csatlakozik, tehát 

a probemod serial megtartása szükséges lehet.) Az IEEE 
1394. . . kezdetű rész viszont csak azoknak szükséges, akik 
FireWire csatolóval rendelkeznek, és használni is szeretnék 
azt. Ekkor hagyjuk bekapcsolva, ha nem használjuk, nyugod- 
tan hatástalanítsuk. 

Az ACPI sorokra szükség lehet. Ezek a fejlett energiagazdál- 
kodást hivatottak kiszolgálni. Amennyiben szeretnénk en- 
nek előnyeit élvezni hagyjuk meg, ha nem, kapcsoljuk ki. 
Az apm-et viszont érdemes meghagyri, hisz kényelmes az 
általa nyújtott szolgáltatás, de nem visz el sok erőforrást. 
Érdemes meghagyni a Serial-ATA vezérlők keresése .. . 
sort is, hisz az ATA merevlemezek támogatását használhat- 
juk általa. Amennyiben készen vagyunk, F2-vel mentsük 

a fájlt, és indítsuk újra a gépet. A jó beállítások esetén min- 
den általunk kívánt eszköz használható marad, de mégis 
szemmel láthatóan gyorsabban éled fel a számítógép. 


Szolgáltatások 

Számtalan alapértelmezett szolgáltatás indul el, amikor tele- 

pítjük az UHU-Linuxot. Ezek közül is van olyan, amire oly- 

kor nincs szükség, feleslegesen foglalja az erőforrásokat. 

Ezen szolgáltatások kezeléséhez az UHU vezérlőpult nyújt 

segítséget. Indítsuk el, és menjünk rá a , szolgáltatások" 

pontra. Itt láthatjuk listában, hogy milyen elérhető szolgál- 
tatásokat futtathatunk, milyen futási szint tartozik hozzá, 
láthatjuk, hogy éppen fut-e, és beállítható, hogy automati- 
kusan induljon-e, vagy sem. Ezekre olykor szükség van, 
olykor nem. Rövidke leírás is tartozik hozzá, hogy melyik 
milyen funkciót végez, tehát könnyen dönthetünk. Most 
csak a kicsit kétségesebb részekre térünk ki. 

—-  ADSL: Erre akkor van szükségünk, ha ADSL kapcsolattal 
rendelkezünk, és az UHU tárcsázóban beállítottunk egy 
érvényes, és működő ADSL elérést. Ekkor ezt a pontot 
aktiválva a rendszer betöltődésekor azonnal indul az 
ADSL kapcsolat is, így ezzel már nem kell törődnünk. 
Alapértelmezetten ki van kapcsolva. 

-  CUPSD: Mindenféle nyomtatási feladatért felelős. 

Ő a nyomtató szerver démon, amire nyomtatóval ren- 
delkező asztali gépeknél szükség van, (hálózati nyomta- 
tóknál is) egy olyan notebook esetében mint ami nekem 
is van már nem. Ilyenkor nyugodtan kikapcsolható. 

—  FAM: fájl állapotváltozás figyelő. Szükséges, hagyjuk 
bekapcsolva. Ez tartja nyílván a fájlok állapotát, követi 
a változtatásukat. 

—  GDM/KDM: ez a gnome, vagy KDE bejelentkezés kezelő. 
Valamelyikre szükség van, hogy be tudjunk jelentkezni 
grafikus felületen, de csak az egyikre. Ha szerkesztjük 
figyeljünk arra, hogy a futási szintje legyen , 57. Ugyanis 
a grafikus szerver ezen a futásai szinten üzemel. 

- nfs, smb: Szerverek. Ezekre csak akkor van szükség, 
ha hálózati meghajtót is akarunk csatlakoztatni, kezelni 
(nfs) illetve szeretnénk windows-os gépekhez csatlakoz- 
ni (smb). Ha nem, nyugodtan kikapcsolható. 

-  ntp: Ez egy érdekes szolgáltatás. Ez a kis démon az 
interneten keresztül hangolja össze a rendszer órát, az 
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internetes órával. Ha az esetek döntő többségében nem 
lesz a gép az interneten felesleges a futtatása, hisz csak 
hálózat esetén használható. Én kikapcsoltam, mivel 

a notebook-om 9090-ban nincs hálózaton. 

-  Postfix: Amennyiben szerverként használjuk a gépün- 
ket úgy, hogy a leveleinket a felhasználó(osajátdomain.hu 
címen akarjuk kiküldeni, szükséges. Ha az internet szol- 
gáltatónk pop/smtp szervereit használjuk, akkor nem 
szükséges. Én kikapcsoltam. 

-  remotefs: más, hálózati fájlrendszerek közötti tallózást 
tesz lehetővé. Ha semmilyen hálózati meghajtóval nem 
akarunk foglalkozni, (novell NIS nfs smbfs) akkor nem 
szükséges. 


Grafikus felület 

Minden eddigi erőfeszítésünk hiábavaló lehet, ha egy, az 

erőforrásokat nagy kanállal evő ablakkezelőt használunk. 

A Linux ebből a szempontból is több alternatívát kínál, így 

a két fő szempont a gyorsaság, és a kényelem igen jól köze- 

líthet egymáshoz. Tekintsük át őket röviden, a legtöbb erő- 

forrást kívánó ablakkezelőtől a legkisebbekig. 

- KDE: A K Desktop Environment a leginkább elterjedt, és 
legkényelmesebb ablakkezelő. Felülete rendkívül tetsze- 
tős, határozottan szép. Szolgáltatásai igen sokrétűek, jól 
konfigurálható, és egy teljesen komplett rendszert 
nyújt. A Kinfocenter remekül tájékoztat a hardverekróől, 
a Koffice egy kellemes kis irodai programcsomag, és 
hosszasan lehetne sorolni a programokat , amiket tartal- 
maz. A teljes KDE felület több mint 250 MB, tehát igen 
nagy. Ez az az ablakkezelő, amelyet a leginkább előny- 
ben részesítenek a kezdő felhasználók, a windows-os fe- 
lületet kedvelők. A KDE 3.2 már eléggé gyorsan éled fel, 
és igen kellemes. Nagy hátránya, hogy a memória mére- 
tével arányos a sebessége. Ugyanis a KDE rendkívüli 
módon eszi a memóriát, így 128 MB rendszermemória 
alatt szemmel láthatóan lassú. Amennyiben a KDE felü- 
leten szeretnénk futtatni az Evolution, OpenOffice, vagy 
Mozilla alkalmazásokat, (esetleg mindet együtt) akkor 
a 256 MB-nyi memória igencsak elkél. A processzor óra- 
jele is legyen legalább 500 MHz, ha szeretnénk, hogy jól 
fusson. Sok ablak megnyitása, illetve a fent említett 
programok egyidejű futtatásakor még így is észrevehe- 
tő, hogy bizony elfoglal nagyon sok erőforrást. Ez ter- 

















mészetesen a több Ghz órajelű processzorok korában 
nem akkora probléma, pláne, hogy manapság az 

512 MB fizikai memória sem szokatlan. Régebbi gépe- 
ken határozottan kényelmetlen lehet, és nem ajánlott. 

- Gnome: Igen fejlett ablakkezelő. Az UHU a 2.4.2-es ver- 
ziót tartalmazza, de az internetről telepíthető a 2.6-os 
gnome is. Ez a legfrissebb. Jóval kevesebb erőforrással 
is beéri mint a KDE, és nagyon kényelmes használata. 

A 128 MB rendszermemória itt is javasolt, de ennyi elég 
is neki. Nem eszi nagykanállal ez erőforrásokat. Ez a fe- 
lület a legalkalmasabb arra, hogy kényelmesen dolgoz- 
hassunk, és kíméljük az rendszer energiáját. Az UHU- 
Linux alapértelmezett felülete is ez. 

-  IceWM: Régi, mondhatni , klasszikus" felülete a Linux- 
nak. Nagyon kevés erőforrást igényel, és a Windows95-öt 
idézi a felülete. Gyors, még elég kényelmes. Néhány 
Linux terjesztés alapértelmezett felülete, (pl: Vector linux). 
64-128 MB alatti memóriával rendelkező gépek ideális 
felülete. 

-  XFCE: A fejlesztése jelenleg a 4.2 verziónál tart. Nagyon 
gyors, és az alkalmazások is nagyon gyorsan indulnak 
rajta. Kicsit szokatlan lehet a kezdő felhasználók számá- 
ra a kezelése, de gyorsan elsajátítható. Sajnos ez a felü- 
let nem támogatja az ikonok elhelyezését a képernyőn, 
helyette egy igen átgondolt menürendszerrel rendelke- 
zik, ahová gyerekjáték új bejegyzéseket felvinni. , súly- 
csoportban" az IceWm-el egyezik meg, és szintén taná- 
csolható a kis gépek felületének. 

-  BlackBox: Ez egy rendkívül kicsi, és villámgyors ablak- 
kezelő. A menü a jobb egérbombbal csalogatható elő, 
betöltődése pedig még régi gépeken is 2-3 másodperc. 
Nagyon kevés erőforrást igényel. Az ikonokat ez sem tá- 
mogatja. Hátránya, hogy a testreszabása némi szakértel- 
met igényel, mivel ehhez a beállító szkriptekben kell el- 
mélyülni. Egyértelműen a haladó felhasználók felülete, 
akik már hozzászoktak az ilyen beállítási módhoz, és 
igyekeznek mind jobban kihasználni a Linux finomhan- 
golhatóságát. 64 MB alatti gépekhez kiváló. 

-  Enlightenment: Egy nem túl elterjedt, és ismert ablakke- 
zelő, de nagyon jó, mondhatnám kiváló. Nem sokkal 
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tart tovább az indulása mint a blackbox-nak, (3-4 másod- 
perc) teljesen animált, kényelmes, és a funkcióinak 
a 9090-át beállíthatjuk grafikus menüből is. Ehhez is sok 
téma tölthető le az internetről, az egyszerűtől az egé- 
szen futurisztikusig. Ezt az ablakkezelőt kezdőknek is 
tudom ajánlani. Szintén alkalmas 64 MB alatti gépekre. 
-  WindowMaker: Ez egy szintén ismert, és régebb óta 
használatos ablakkezelő. Régi motorosok jól ismerik. 
Gyors, kevés erőforrást eszik, és nem támogatja az iko- 
nos elrendezést. Pontosabban támogat valami olyasmit 
mint az ikonok, de korántsem abban a formában, amire 
az ember először gondolna. A WindowMaker a képer- 
nyő oldalán, és alján helyezi el ezeket, és nem a képer- 
nyő középső felületén. Így könnyen elérhető, mindössze 
kicsit szokatlan lehet. Szintén jó alternatíva a 64 MB 
alatti gépeknél. 


Egy jól megválasztott ablakkezelő sokat javíthat a rendsze- 
rünk sebességén, terhelhetőségén. Általános recept erre sin- 
csen, főleg.hogy az ablakkezelő megválasztása is inkább 
vallási kérdés. Persze kis gépen a KDE választása nem sze- 
rencsés választás, de általánosságban elmondható, hogy az 
erőforrás beosztás szempontján túl mindenki megtalálhatja 
azt az alternatívát, ami neki a legjobban tetszik, vagy a leg- 
hasznosabb. 


A Rendszermag kezdőknek 

A Linux lelke a rendszermag. Pontosabban (és ez a helyes 
megfogalmazás) a Linux maga a rendszermag. Minden más 
ami körülötte van, (programok, héj, stb...) csak egy nyílt 
forrású program, amely a Linux (a kernel) köré van helyez- 
ve, különböző feladatokkal. Amikor tehát a magot fordítjuk 
forráskódból, gyakorlatilag a Linuxot fordítjuk le. 

Az UHU-Linux magja egy ,általános" kernel, úgy elkészít- 
ve, hogy telepítés után a lehető legtöbb gépen használható, 
és működőképes legyen. Tömören, és lényegretörően meg- 
fogalmazva, a telepített kernelnek nem sok köze van a gé- 
pünkhöz. Sok olyan dolgot is tartalmaz, amelyre nekünk 
semmi szükségünk nincsen. A jól beállított, és az adott gép- 
hez fordított kernel nagyon stabil, és gyors működést tesz 
lehetővé. 

A rendszermag fordítása messze meghaladná eme leírás ke- 
reteit, ezért nem is vesszük át alaposabban. Mindössze pár 
gondolatra térünk ki, amely segítség lehet a kivitelezésben, 
a kezdő felhasználók számára is. 

Az UHU alapértelmezett magja a 2.4.24-7-es verziószámot 
viseli. Ahhoz, hogy tudjuk fordítani, szükséges a forráskód. 
Ehhez kétféle módon juthatunk. Az UHU-Linux második 
CD lemezéről, vagy az internetről. Mindenképpen javasolt 
az internetes telepítése. Ugyanis a CD lemezen található 
forráskód az UHU-Linux 1.1.1 kiadási időpontjában uralko- 
dó állapotokat tükrözi, így minél távolabb van ez az idő- 
pont a jelentől, annál több hibajavításnak van híján. Az 
nternetes változat" azonban folyamatosan frissítve van, 
így tartalmazza a lehető legfrissebb javításokat, foltokat is. 
Ennek a forráskódnak a telepítése az apt-get el történik. 
Apt-get install kernel-source 


Ne lepődjünk meg, ha az apt-get először a kernel-headers 
csomagot telepíti. Erre feltétlenül szükség van. 
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Amikor az apt-get készen van, mi is munkához láthatunk. 
Kétféle módon is beállíthatjuk a kernel konfigurációt. 
Először lépjünk be a kernel forrásának a mappájába konzol- 
ról, természetesen rendszergazdaként. 

cd /usr/src/linux 


Ezután kétféle felületről konfigurálhatunk; A make xconfig 
paranccsal egy teljesen kulturált grafikus felületű beállító- 
programot kapunk. A make menuconfig viszont egy DOS-os 
időkből ismert grafikus képernyőt ad, ahol a kurzor moz- 
gató billentyűkkel lehet manőverezni. Ekkor munkához lát- 
hatunk, és megszerkeszthetjük a saját, a gépünknek legin- 
kább megfelelő konfigurációt. Az így elkészített, és elmen- 
tett konfigurációt fogja használni a fordítóprogram, amikor 
lefordítja a forráskódot. Ehhez a beállítások végeztével ad- 
juk ki a make bzImage utasítást. 

A beállítások során sokszor háromféle lehetőségünk van. 

A kívánt funkciót belefordíthatjuk a rendszermagba, ekkor 
a bzlmage fogja tartalmazni. Választhatjuk azt is, hogy mo- 
dulként legyen jelen (ekkor valami.o-ként fordul le, de nem 
tartalmazza a bzlmage), vagy el is távolíthatjuk a funkciót. 
Ebben az esetben a fordító a jövőben nem fog foglalkozni 

a forrásával. 

Az UHU alapértelmezett rendszermagjának a fordításakor 
funkcionális hátránya nem lesz, ha nem fordítunk modult, 
hisz az alap kernel moduljai már léteznek a /lib/modules 
alatt. Ha új modult nem akarnuk fordítani, akkor a make 
modules és a make modules install] parancsok elhagyható- 
ak, és elégséges csak a bzImage fordítására koncentrálni. 
Érdemes kitérni egy fontos tényre. Az eddigi gyakorlattal 
ellentétben, az alternatív kernel-smp az 1.1.1-ben már nem 
létezik. Tehát a több processzoros támogatás már nem kü- 
lön kernelt igényel, hanem mindössze csak be kell kapcsol- 
ni a konfigurációban. Ez alapértelmezetten be van kapcsol- 
va, és érdemes is úgy hagyni, még akkor is, ha tudjuk; csak 
szimpla processzorhoz fogjuk használni. Ugyanis tapaszta- 
latom szerint ha ezt kikapcsoljuk, fordítási hiba lép fel. 

Az új, immár a mi gépünkhöz fordított rendszermag 

a /usr/src/linux/arch/i386/boot/bzImage néven található meg. 
Ezt kell bemásolni a /boot mappába, ahol a grub a rendszer 
betöltésekor keresni fogja. 

Amennyien nem vagyunk gyakorlottak a rendszermag for- 
dításában érdemes átnevezni mondjuk bzImage1-re, és en- 
nek külön bejegyzést írni a /boot/grub/menu.1st-ben. Így 
ugyanis egy rossz beállításokkal fordított rendszermag elin- 
dítása után még nem lesz használhatatlan a gép, és hiba 
esetén még mindig használható az alapértelmezett. 

Ha azonban szeretnénk a legújabb rendszermagot használ- 
ni amit elkészítettek, akkor a 2.6-ost fordítjuk. A legfrissebb 
verzió a cikk írásának időpontjában a 2.6.7-es. Ennek a for- 
ráskódját a 5 http:/www.kernel.org weboldalról tölthetjük 
le. Ha letöltöttük a megfelelő forráskódot, akkor kicsomago- 
lás után szintén lépjünk be rendszergazdaként a forráskód 
gyökérkönyvtárába, és ott adjuk ki a make xconfig, vagy 
make menuconfig parancsot. 

Figyelem! A 2.6.x-es kernel teljesen új keletű fejlesztés. Szá- 
mos, a 2.4.x-ben nem található újdonságot tartalmaz. Min- 
denképpen javasolt az idevágó fórumok olvasgatása, a ta- 
pasztaltabb felhasználókkal való konzultáció, vagy az adott 
újdonsághoz tartozó súgó elolvasása a beállítóprogramban. 
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Egy jól fordított 2.6.x-es rendszermag szintén nagyon sokat 
gyorsíthat a rendszerünkön, mivel új ütemezőjével, memó- 
riakezelésével, és kernel szintű eszközgyorsítási (pl: egér) 
képességével meglepő plusz sebesség erhető el. 

További fontos megjegyzendő, hogy a 2.6.x-es, és a 2.4.x-es 
kernel nem jól dolgozik össze. Tehát a 2.6.x-es kernel fordí- 
tásakor feltétlenül fordítanunk kell a modulokat is, a make 
modules parancssal, és telepítenünk a /lib/modules alá 

a make modules instal1 utasítással. 

Ha készen vagyunk, és az új kernel hibátlanul üzemel, és 
elégedettek is vagyunk vele, nyugodtan törölhetjük az új 
bejegyzést a grub-ból, hogy az új rendszermag legyen az 
alapértelmezett. 


Programok 

A programok kérdéskörét nagyon sokszor elfelejtik a rend- 
szerek hangolásánál. Egy adott feladatra létezhet nagyobb, 
és kisebb erőforrás igényű program, holott mindkettő tudja 
azt, amire szükségünk van. Általában egy adott program 
használatában sokkal inkább a megszokás dominál, mint 

a program tudása. Érdemes lehet átnézni a menüket, hogy 
egy adott funkcióhoz milyen programok léteznek, és mikor, 
melyik alkalmas a kívánt feladat végrehajtására. A kisebb, 
de nagyon gyors program használata jobb választás lehet, 
mint egy nagy, lassú, mely tudásának csak kis részére van 
szükségünk. Ez szintén teljesen egyén-, rendszer-, sőt fel- 
adatfüggő. 

A Mozilla nagy és lassú. A feladatát (böngészés) jobban el- 
végezhetjük a FireFox,vagy az Opera segítségével. Az Ope- 
rát nagyon melegen tudom ajánlani. Kicsi, és nagyon gyors, 
ráadásul bámulatosan nagy tudású böngésző, amelynek je- 
lenleg a 7.51 verziója érhető el. Aki ismeri nem kell magya- 
ráznom miért kiváló, aki nem, annak csak javasolni tudom 
a kipróbálását. Az Abiword nagyon szimpatikus kis szöveg- 
szerkesztő, ráadásul legalább kétszer olyan gyors, mint az 
OpenOffice.org. Egyszerű, sima dokumentumok szerkesz- 
téséhez szerintem jobb választás. 

Az Evolution nagyon jó program, ám aki csak levelezni 
akar, annak nagy, és felesleges. Ajánlható a Kmail, vagy 

a Sylpheed. Csevegéshez lomha lehet a Mozilla IRC-je, 

de még az Operáé is. Ekkor használhatjuk az Xchat, Ksirc, 
BitchX programok valamelyikét. Mindegyik nagyon jó, és 
kellően kevés erőforrást eszik, miközben a feladatát tökéle- 
tesen ellátja. A sort hosszasan lehetne folytatni. Érdemes 
egyszer átnézni a menüket, hogy mégis milyen programok- 
kal rendelkezünk, az adott feladathoz. Egy a jól megváloga- 
tott program készlet gyors, hatékony munkát tesz lehetővé 
úgy, hogy a megfelelő tudásukban se legyen hiány. 

A fent leírt módokon, és egy jól beállított rendszer, jól fordí- 
tott 2.6.x-es rendszermaggal akár 60970-al is gyorsabban töltőd- 
het be, és futhat. Rendkívül sok erőforrás takarítható meg, 
vagy használható ki jobban, hogy a rendszerünk valóban 
úgy működjön, ahogyan az a legoptimálisabb. Természetesen 
gyorsabb működés nem létezik annál, minthogy az adott 
rendszer/programok az adott géphez legyenek fordítva (ala 
gentoo, ami bámulatosan gyors) de anélkül is sokkal jobb mű- 
ködés alakítható ki, ha nem az alapban telepített rendszert 
használjuk, hanem gépünkhöz, igényeinkhez igazítjuk. 


Dancsok , strogg" Zoltán 











BootSplash képernyő Uhu-Linuxon! 


Hozzunk létre UHU linux alá is csinos háttérképeket a bootoláshoz! 


megfelelő anyag birtokában, minimális gyakorlat- 
A tal ez mindössze 15 perc szöszmötölés után 

elkészül. Ennyit pedig messze megér a végered- 
mény. A probléma megoldásához több dologra is szükség 
van. Egy rendszermag forráskódra, egy rendszermag foltra, 
ami ezt a funkciót hozzáadja a fordítható rendszermaghoz, 
egy bootsplash-készítő segédprogramra, egy témára, és kö- 
rülbelül 15-20 perc szabadidőre. Az UHU-Linux esetében 
a rendszermag forráskódja könnyen telepíthető az apt-get 
install] kernel-source parancsal. Ez letölti, és telepíti 
a kernel-header csomagot is. Ha ez megvan, akkor a szer- 
számosláda többi elemére van már csak szükségünk. A 
5 http:/www.bootsplash.. org kifejezetten ezzel foglalkozik. 
Sót, pár témát is találunk itt, és teljes leírásokat. Lássunk 
munkához! Az említett oldalról töltsük le a kernel stuff me- 
nüpont alól a megfelelő kernel foltot. Látható, hogy a 2.6.x, 
és a 2.4.22-höz vannak itt javítások. A verziószámok ne Zza- 
varjanak meg senkit, a 2.4.22-es tökéletesen működik az 
UHU 2.4.24-7-es kernelével. Ha letöltöttük a megfelelő bz2 
fájlt, akkor csomagoljuk is ki. Ha ezzel is megvagyunk, ak- 
kor semmi más teendőnk nincsen, mint feljavítani a telepí- 
tett rendszermag forráskódját. Konzolban jelentkezzünk be 
rendszergazdaként a su-val. Lépjünk be a rendszermag for- 
ráskódjának a mappájába, a cd /usr/src/Tinux parancsal. 
Ha itt vagyunk, végezzük el a forrás foltozázását: 


patch -pi c /eleresiút/bootsplash-3.0.7-2.4.20- 
s vanilla.diff 


Ha hiba nélkül lefutott a parancs, akkor a jövőben fordított 
kernel már képes lesz megjeleníteni a bootsplash képernyőt. 
Indítsuk el hát a rendszermag konfigurációs programját 

a make menuconfig utasítással. Keressük meg a Console 
drivers -2 Frame-Buffer support részt, és engedélyezzük 

a VESA-VGA graphics console pontot. Ezután engedélyez- 
zük a Use splash screen instead of boot logo pontot is. Ezzel 
meg is volnánk. Figyelem! A kernel ekkor még az alapbeállí- 
tásokat tartalmazza. Érdemes átnézni, hogy még mire van 
szükségünk a fordítás elött. És mivel a kernel, és a modulok 
verziója egyezik, elhagyható a make modules, és a make 
modules. install parancs. Elég csak a bzlmage-et fordítani. 
Ha készen vagyunk, akkor bátran fordítsuk le az új kernelt, 
a make bzImage parancsal. A fordítás után a kész bzlmage-t 
célszerű átnevezni a tesztek erejéig, mondjuk bzlmage1-re, és 
úgy bemásolni a /boot konyvtárban található eredeti bzImage 
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mellé. Célszerű, ha lemásoljuk a /boot/grub/menu.1st fájlban 
az indító bejegyzést, és az új bejegyzésben hívjuk meg 

a bzImage1-et. Ezáltal gyakorlatilag 2 üzemképes kernellel 
rendelkezünk, és hiba esetén nem válik használhatatlanná 

a gépünk. Ezután még két dologra van szükség. Egy témára, 
és egy programra, amely a kernel számára ,ehető" formába 
hozza a képeket. Ehhez töltsük le a bootsplash-3.0.7.tar.bz2 
fájlt, és tömörítsük ki. A kapott forráskód könyvtárába belépeve 
adjuk ki a make, és amake instal1 parancsokat. Ezzel lefordít- 
juk a programot, és telepítjük. Győzödjünk meg róla, hogy 
telepdett a /usr/sbin könyvtárba. Ezután töltsünk le egy nekünk 
tetsző témát. A letöltött bz2 fájl kitömörítés után azonnal 
haszálható. A kicsomagolt téma fájljai közül mindössze 3 dolog- 
ra van szükség. A bootsplash-1024x768.jpg, a silent-1024x768.jpg 
és a bootsplash-1024x768.cfg fájlokra. Most Midnight 
Commander-rel menjünk rá a .cfg fájlra, F4-el nyissuk meg, 
Vusr/share/splash)/... jpg) Amikor ez is megvan, akkor már csak 
létre kell hozni a megfelelő állományt, amit látni fogunk a boot 
folyamat során. Ehhez adjuk ki a következő parancsot. 


/sbin/splash -s -f /usr/share/splash/bootsplash- 
5 1024x768.cfg 5 /boot/initrd.splash 


Ha gond nélkül lefut, akkor létrejött egy a /boot mappában, 
az eredeti initrd mellett, egy initrd.splash fájl. Ez az, amire 
szükségünk van. Módosítsuk a /boot/grub/menu.1st fájlt is- 
mét. Ezuttal azonban az új kernel (bzImage1) bejegyzését 
véglegesítjük. Utasítsuk, hogy a képernyőt kapcsolja a meg- 
felelő felbontású VESA módba. Ezt a vga-791 utasítással te- 
hetjük meg. Ha a silent képet választjuk, akkor a teljes boot 
során egy képet mutat, míg verbose módban a kódsorok 

a kép elött futnak. Az initrd-re utaló sort javítsuk át úgy, 
hogy az initrd.splash-ra mutasson. Az egész tehát ilyen lesz: 


title UHU-Linuxisplash 

kernel (hd0o,1(/boot/bzImageil 
root-/dev/ide/host0/busO0/1un0/part2 vga-791 
5 splash-silent 

initrd (hdO0,1)/boot/initrd.splash" 


Ezután dőljünk hátra, és indítsuk újra a gépet. Ha mindent 
jól csináltunk, már gyönyörködhetünk is a képben. 


Dancsok , strogg" Zoltán 
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Kiadja: Kiskapu 
Felh. szint: kezdő 
Ár: 2800,- 


A katedrális 
és a bazár .......... 


Cd melléklet: nincsen 


244 old. 


Eric 5. Raymond: A katedrális és a bazár 
A nyílt forráskód forradalma és története 


Eric S. Raymond A katedrális és a bazár című könyve egy 
olyan mozgalmat, egy olyan szemléletet mutat be, amelyet 
a nagyközönség Magyarországon csak mostanában kezd 
megismerni. A nyílt forráskódú szoftverek, a nyílt forrású 
fejlesztés pár éve még úgy tűnt, mint néhány megszállott 
hobbija, semmi több. A nagy szoftveróriások ontották ma- 
gukból a termékeket, szívták (f)el a nagytudású fejlesztőket, 
és mindenki őket tekintette az informatikai fejlődés moz- 
gatóinak. Aztán a 90-es évek elején, a Helsinki Egyetem 
egy diákja egyedi ötlettel állt elő, amely — bár sokan 
tamáskodva fogadták — mára alapjaiban rengette meg 

a szoftveripart és változtatta meg az addig szentnek és 
sérthetetlennek hitt fejlesztési felfogást. 

A Linux fejlesztési módja felrúgott minden addig használt 
szabályt, sémát. Nem jól szervezett fejlesztői csoportot hoz- 
tak létre, hanem közösséget szerveztek. A közösség tagjai 
látszólag ugyan szervezetlen csoportot alkottak, akik szer- 
vezetlen módon működnek, és ez sokakat eltántorított a 
csoport munkájának támogatásától. De a dolog valahogy 
mégis működni kezdett, és ahelyett, hogy sokak várakozá- 
sának megfelelően átláthatatlan káoszba süllyedt volna 

— virágozni kezdett. Egyre több és több szakember kapcso- 
lódott be a Linux fejlesztésébe, újabb és újabb projektek in- 
dultak. És mindez éppen egybeesett az Internet robbanás- 
szerű elterjedésének idejével, ami újabb lökést adott a 
Linuxnak. Mivel annak gyökerei az Internet ősének tekint- 
hető ARPAnet hálózathoz csatlakozó Unixos rendszerekhez 
vezethetőek vissza, nem volt kétséges, hogy rövid idő alatt 
az Internetes kiszolgálók és munkaállomások uralkodó 
rendszerévé lép elő. 

A könyv egy bennfentes tapasztalatain keresztül betekintést 
ad a nyílt forráskódú fejlesztés világába, bemutatja a fejlesz- 
tők csoportjait. Rámutat olyan ellenmondásokra, mint a 
nyílt forráskódú, szabadon használható szoftverek és a tu- 
lajdon kérdése, bemutatja a közösség mozgatórugóját, a fej- 
lesztők egymással vívott presztízs-csatáját továbbá betekin- 
tést nyerhetünk egy olyan kreatív közösség életébe, amely 
a mai üzleties szemléletmód nélkül is sikerre tudta vinni öt- 
letét. Annak is érdekes olvasmány a könyv, aki kicsit üzleti 
szempontból tekint a szoftverfejlesztésre. A könyv bemutat 
néhány téveszmét a nyílt forrású projektek finanszírozásá- 
val kapcsolatban, valamint mutat kilenc modellt ezen pro- 
jektek finanszírozására. 

A könyv ma még ,csak érdekes olvasmány", de lehet, hogy 
pár éven belül kötelező irodalommá válik. 
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4 VÁLTS LINUXRA! 


Búcsú a kékhaláltól 


Váltsunk Linuxra Marcel Gagné-val 
Egy újabb útmutató a Linuxra váltóknak 


Marcel Gagné Válts Linuxra! című könyve alapos útmutató 
kezdő Linux felhasználóknak. A könyv az első gondolatok 
megszületésétől segíti a felhasználót a Linuxra való átállás 
során. A szerző a Linux bemutatását egészen az alapoktól 
kezdi. Első lépésben felteszi és meg is válaszolja a témával 
ismerkedőkben felmerülő kérdést: Valóban ingyenes?" 

A könyv első fejezetében megismerkedhetünk a GPL 
licenceléssel, a Linux által nyújtott biztonsággal, megbízha- 
tósággal és teljesítménnyel. A könyv ugyanakkor nem elva- 
kult, tisztában van az újdonsült Linuxos felhasználóknál je- 
lentkező problémákkal is. Van egy nyomtatóm, hangkár- 
tyám, lapolvasóm, régi jól megszokott programom. Miért 
nem működik?" A könyv foglalkozik a felhasználók által ta- 
pasztalható kisebb-nagyobb problémákkal is, így biztosítva 
azt, hogy senkit ne érjen váratlan csalódás a rendszer tele- 
pítése után. És ha már problémák felmerüléséről beszélünk, 
említsük meg, hogy a könyv nem megy el ezek mellett. 
Segíti az olvasót abban is, hogy ezekre a kisebb-nagyobb 
gondokra hol találhat gyógyírt. 

A rendszer telepítése jól átgondolt ív mentén halad. Nem 
feltételezi egyik, vagy másik Linux kiadás meglétét, általá- 
nosságban mutatja be a csomagokat. Ez egyfelől előny, hi- 
szen minden kiadás használója forgathatja a könyvet, más- 
felől feltételez némi talpraesettséget az olvasóról, de úgy 
gondolom ez a mai számítástechnikai világ velejárója. 

Első lépésben telepítünk egy tetszőleges Linuxot, beállítjuk 
a rendszer indítását, felkészülünk a mindennapi munkához 
szükséges eszközök telepítésére. Második lépésben a szerző 
leírja, hogy miként telepítsük, konfiguráljuk és használjuk 
az egyik legnépszerűbb grafikus környezetet, a KDE-t. 

A KDE bemutatása után következhet a KDE fontosabb 
programjainak ismertetése, így egy teljes fejezetet kapott 

a Kongueror. A szerző külön fejezetet szentel a számítógé- 
pünk különböző eszközeinek telepítésére, de az internetes 
kapcsolat beállítására és az elektronikus levelezésre is. Ter- 
mészetesen a különböző típusú felhasználói programokról 
sem feledkeztek meg, így a könyvből megtudhatjuk milyen 
irodai programot használjunk, hogyan állítsuk be és hasz- 
náljuk a lapolvasónkat, vagy mivel tudunk zenét hallgatni 
és videót nézni. 

A könyv hasznos olvasmány mindenkinek, aki meg szeret- 
ne ismerkedni a Linux használatával a mindennapokban. 
Kezdőknek csak ajánlani tudom. 


Illés Viktor 











Keresztplatform? Helyes! 


Linux alapú fájlkezelők könnyítik meg állományaink és nyomtatóink kezelését 
örökölt Microsoft Windows rendszereinken. 


gen, Francois elismerem. Ez valóban nagyon vicces. 
] De amikor a múltkor említettem, hogy e havi témánk 

a kereszt-platform fejlesztés lesz, nem olyan platformokra 
gondoltam, amitől keresztbe állnak a szemeid, bár megértem, 
hogy néhány operációs rendszer kapcsán erre gondoltál. 
Amilyen elbűvölő kis képek ezek, azt hiszem a mai menü- 
höz kiválasztott művek láttán lesznek akik felvonják majd 
a szemöldöküket, még ha közönségünk igen megértőnek 
mondható is. Miről is fecsegek itt, hiszen a mi kedves ven- 
dégeink már meg is érkeztek. 
Üdvözlet, mes amis, Chez Marcelnél, a különleges Linux 
csemegék otthonában. Helyezzék magukat kényelembe. 
Francois és jómagam éppen az e havi témáról, 
a rendszerfüggetlen fejlesztésről beszélgettünk, és kedvenc 
pincérem talán kicsit túl lelkes volt. Már-már úgy tűnhet, 
hogy ehhez egy fehér Zinfandelt kell hoznunk, de szeren- 
csére ilyet éppen nem tartunk. Francois, a pincébe, 
immédiatement! Hozzd fel 1992-es Napa Valley-i Cabernet 
Sauvignon-t. Vite! Amint azt bizonyára sokan tudják, a Mic- 
rosoft Windows továbbra is része az átlagos üzleti IT világ- 
nak. Sokunk számára létfontosságú, hogy meg tudjuk olda- 
ni a Windows és Linux közötti információcserét. Tegyük fel, 
valahogy sikerült meggyőznünk a vezetőséget, hogy Win- 
dows helyett Linuxot futtathassunk a munkaállomásunkon. 
Esetleg saját notebookunkat használjuk. Bármi legyen is az 
indok, meg kell birkóznunk a Windows munkacsoportok- 
kal vagy tartományokkal, valamint a megosztott állomá- 
nyokkal és nyomtatókkal. Bár Judit a könyvelésen nem kü- 
lönösen kedveli Windows XP gépét, igen sok megosztott ál- 
lomány található meg itt, olyan állományok, amelyeket 
a hálózati kapcsolatokon keresztül érhetünk el. Azt kérdez- 
hetnénk magunktól, vajon mennyire nehéz a hálózati kap- 
csolatok nyújtotta előnyöket kihasználni. Nos, ez egy igen 
érdekes kérdés, tekintve, hogy milyen sok olyan fájl és 
nyomtatókiszolgáló található, amely valójában nem Win- 
dows-t, hanem a fájlszolgáltatásokat Samba rendszerrel 
kezelő Linuxot futtat. Ezek után nem is meglepő, hogy 
a Samba-val együttműködő ügyfélprogramok lassan kezde- 
nek minden új Linux terjesztés részévé válni. Így aztán az 
smbclient programmal könnyedén felkapcsolódhatunk 
a hálózat Windows megosztásaira. Indulásként adjuk ki az 
smbclient -L sedna parancsot, amely a megosztások listáját 
adja vissza a következő alakban: 
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smb//accountngy- Konguerőr; 
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E3 Location: ( (3 smb://accounting/ [e] "el 
——— 
ACCOUNTING MDKGROUP F SEDNA 
WINECELLAR ULTRAMAN 
(TB ltems - 0 Files - 3 Folders FT 183 tems - 0 Files - 3 Folders d 
1. ábra Munkacsoport böngészés Kongueror-ral 
Domain-[ACCOUNTING] 05-[windows 5.1] 
Server-[windows 2000 LAN Manager] 
Sharename Type Comment 
SEDNA C Disk 
IPC$ IPC Remote IPC 
Reports Disk 
Policies Disk 


Feltételezve, hogy van jogosultságunk a Reports mappa el- 
éréséhez, a következőképpen csatlakozhatunk hozzá: 


smbclient //sedna/reports -U winuser 


A fenti példában Linux gépemről winuser néven jelentke- 
zem be a Windows XP gépre. A rendszer ezután jelszót kér, 
majd a samba parancssorba jutunk amely a következőkép- 
pen néz ki: 


Domain-[ACCOUNTING] 05-[windows 5.1] 
Server-[windows 2000 LAN Manager] 
smb: e 


Itt adjuk ki a help parancsot és az smbclient megmutatja 
nekünk, milyen parancsokat használhatunk a kapcsolat 
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ideje alatt. Sok közülük egyértelmű, ilyen a dir, copy és tár- 
sai. Ugyan ez sem rossz megoldás, de vizuális értelemben 
nem valami csinos, és grafikus fájlkezelőnkben sem tudjuk 
használni, nem beszélve az OpenOffice.org alkalmazásairól. 
Akár KDE, akár GNOME rendszert használunk asztali kör- 
nyezetként, biztosak lehetünk abban, hogy rendelkezésünkre 
áll a hálózati kapcsolatok kiépítéséhez szükséges eszköztár. 

A legjobb az egészben, hogy mindezt rendkívül egyszerűen 
tehetjük meg. Először vessünk egy pillantást a Kongueror-ra. 
Nyissuk meg a Konguerort (akár a fájlkezelőt akár a böngé- 
szőt) és gépeljük be az smb: // kifejezést a Location mezőbe. 
A hálózati megosztásaikat hirdető Samba kiszolgálók és Win- 
dows gépek már meg is jelennek a böngésző ablakában saját 
munkacsoport nevük alatt (például AZCOUNTING, 
SALESGRP). Az 1. ábrán egy Kongueror alkalmazást látha- 
tunk két-paneles nézetben; kattintsunk a menüsorban 

a Window elemre és és válasszuk a Split View, Left/Right pon- 
tot. A baloldali panelen találjuk a három aktív munkacsopor- 
tot tartalmazó alap hálózati böngésző nézetet. A jobb oldali 
panelen az AZCCOUNTING munkacsoporton kattintottam 
egyet, hogy lássam milyen gépek tartoznak a csoporthoz. 
Ettől kezdve minden a szokásos fogd-és-vidd grafikus fájl- 
böngésző módszerrel történik. Kattintással, be tudok lépni 

a cooking mappába, kikereshetem a megfelelő dokumentu- 
mot, amit meg szeretnék nyitni. Általában persze nem szeret- 
nénk állandóan végigjárni az egész navigációs utat. Néhány 
kattintásnyival közelebb hozhatjuk megosztásainkat, ha az 
elérési utat betesszük könyvjelzők közé. Ha a GNOME felől 
közelítjük meg a dolgokat, ott van nekünk a Nautilus. 

A módszer nagyon hasonló a Kongueror esetében látottak- 
hoz. Indítsuk el a Nautilust és gépeljük a Location sorba az 
smb : // kifejezést. A Nautilus megmutatja nekünk milyen ak- 
tív munkacsoportok vannak a hálózatunkon. A gép kiválasz- 
tásához kétszer kattintsunk az egyik munkacsoporton. A szá- 
mítógépek listájából válasszuk ki a nekünk tetsző gépet és 
máris választhatunk a felajánlott erőforrások közül. Akárcsak 
az iménti Kongueror példánkban, megtakaríthatunk egy kis 
időt, ha a kiválasztott mappát a könyvjelzők közé mentjük. 
Mindkét javaslattal csak az a gond, hogy egyik sem teszi lehe- 
tővé a hálózati meghajtók állandó felcsatolását. A kiválasztott 
mappa eléréséhez egy kis parancssori munkát is kell végez- 
nünk, ami nem túl nagy feladat, de nem is afféle kattintgatós 
megoldás, amit a Windows felhasználók szeretnének látni 

a rendszerünkön. Kérjük meg Francois-t, hogy töltse meg új- 
ra poharainkat mi pedig addig megnézzük, milyen megoldást 
találhatnánk erre a problémára. Ha kicsit rugalmasabb mód- 
szert keresünk a hálózati kapcsolataink kezelésére, csak egy 
pillantást kell vetnünk az Smb4K nevű szuper-klasszis SMB 
böngészőre, amely egyszerre hatékony és rugalmas. Ráadásul 
az Smb4AK segítségével előre megnézhetjük a megosztásokat, 
sőt, rendszergazdai jogosultság nélkül is felcsatolhatjuk, indu- 
láskor automatikusan csatlakoztathatjuk és egyéb dolgokat 
művelhetünk velük. A cikk születésekor az Smb4K még csak 
a 0.3.2 kiadásnál tartott, de igen hasznos csomagnak találtam 
amely egyértelműen megéri a vizsgálódásra szánt időt. Az 
SmbAK telepítését forrásból a szokásos tömörítünk és fordí- 
tunk ötlépéses folyamattal végezzük: 


tar -xzvf smb4k-0O.3.2.tar.gz 
cd smb4k-0.3.2 
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2. ábra Smb4K: lehet, hogy ez a tökéletes SMB böngésző? 


./configure --prefix-/usr 
make 
su -c "make install" 

A csomag telepítése után az smb4k paranccsal indíthatjuk. 
Az SmBAK indulása után azonnal hozzálát a hálózat feltér- 
képezéséhez, kikeresve az aktív megosztásokat. A képessé- 
geket testre is szabhatjuk a menüsor Settings pontja alatti 
Configure Smb4K pont segítségével. Beállíthatjuk például, 
hogy szeretnénk-e, ha a megosztások automatikusan újra- 
csatlakoznának. A grafikus felület könnyen tanulható és jól 
kezelhető. Az egész csomagot nagyon egyszerű használni. 
A képernyő bal oldali kezelőpaneljén találjuk a munkacso- 
portok, számítógépek és megosztások felsorolását. A megosz- 
tás felcsatolásához jobb gombbal kattintsunk a néven és vá- 
lasszuk a mount parancsot. Ha előbb szeretnénk megtudni, 
mit is találunk az adott helyen, inkább a Preview pontra kat- 
tintsunk. A felcsatolt meghajtók a jobb felső ablakban meg- 
hajtó ikonként látszanak. Az egyik meghajtó ikonon duplán 
kattintva megnyílik a Kongueror. Ha parancssorból kiadjuk 

a df parancsot, láthatjuk, hogy a meghajtók használatra ké- 
szen felcsatolódtak, mégpedig saját könyvtárunk alá az 
Smb4K útvonal előtaggal. A 2. ábrán bemutatott példának 
megfelelő lista a következőképpen nézne ki: 


Filesystem Size Used Avail Use9 Mounted on 
//SEDNA/Reports 4.0G 3.OG 1.1G 759 

5 /home/marce1/smb4k/SEDNA/Reports 
//FRANCOIS/wine  13G 8.8G 3.3G 
5 /home/marce1l/smb4k/FRANCOIS/wine 
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Mostantól bármilyen alkalmazásom - legyen az KDE, 
GNOME, héjprogram-alapú vagy bármi más — könnyen el- 
érheti a megosztásokat. A hálózati szomszédságunkba láto- 
gatni soha nem volt még ilyen egyszerű. 


Következő találkozásunkig, mes amis, igyunk egymás 
egészségére. A vötre santé! Bon appétit! 


Linux Journal 2004. július, 123. szám 


Marcel Gagné 





TETT 





VI. GNU/Linux Konferencia 
Felhívás előadóknak! 





A Linux-Felhasználók Magyarországi 
Egyesülete 2004 novemberében 
(szombati napon) rendezi meg a VI. 
GNULLinux szakmai konferenciát. Az 
előadásokat délelőtt 10:30-tól este 
17:30-ig tartjuk. 


Előadók jelentkezését várjuk az alábbi 
jdr dot iak 

-— Rendszeradminisztráció 

— Biztonság 

- Programozás Linuxon 

— Multimédia, grafika 

— Honosítás 


— Hazai fejlesztések 
— DTP Linuxon 


— Linux az üzleti életben 


— Linux felhasználói lehetőségek 
-— Linux az oktatásban/államigazgatásban 


— Egyéb érdekes, Linux-hoz kapcsolódó 
ate 


Az előadásvázlatok beérkezésének határideje: 


augusztus 10. 00:00. Ekkorra tervezzük 

a konferencia honlapjának a megnyitását is, 
ahol azonnal elindul az előregisztráció és 

a vázlatok közötti szavazás, ezért kérnénk 

a határidő betartását. 
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A vázlat javasolt mérete egy A4-es 
gépelt oldal (0.5-1kByte), amit az 
abstractolme.linux.hu címre várunk. 


Az előadások előzetes válogatásáról 
augusztus 14.-ig küldünk értesítést. 

A végleges cikkek leadásának határideje 
szeptember 30., a prezentációké pedig 
október 7. Nyomtatásban már megjelent, 
vagy a konferencia időpontjáig megjelenő 
írást nem lehet beküldeni. 


Az előadás anyagainak formátumára 
vonatkozó követelmények a 


5 http://lme.linux.hu/rendezvenyek/ 
konferencia/kiadvanyforma.html 
oldalon találhatóak meg. 


A konferencia kiadványába csak a határidőre 
beérkező anyagok kerülnek be, amelyek közül 
a közönségszavazatok alapján legjobbnak 
minősülők kerülnek előadásra. 


Az előadókat, mint mindig, VIP-vendégként 
üdvözöljük, azaz ebédhez és egyéb 
szolgáltatásokhoz jutnak. 


A legjobb előadás — közönségszavazatok 


alapján — jutalomban részesül a konferencia 
végén. 


Az LME elnöksége 
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Deus Ex: A játék! 


Igen, a cím magáért beszél. Ez A Játék. Maga a program elvileg semmiben sem 
különbözik egy sor másik, hasonló darabtól, amelyek globális összeesküvés- 
történetet, remek grafikát, és zenét vonultatnak fel. A Deus Ex azonban ezt olyan 
magas szinten, és olyan kidolgozottan teszi, amely a kiadásakor egyedülállóvá 
tette. FPS és RPG keveréke, játékmenetével pedig a stílus legjobb darabja lett. 


történet 2052-ben játszódik. 
A világ káoszba süllyedt. 
Rengeteg a szegény ember, 


a hajléktalan, a lét bizonytalan. Óriás- 
cégek uralkodnak, amelyek árnyék- 
szervezeteik révén amolyan sötét irá- 
nyítóként állnak a kormányok mögött, 
és felett. Ebben a világban a bűnözés 
teljesen összefonódott a legális üzlet- 
tel, a törvényt egyénileg értelmezik. 
És teljes mértékben globális a terroriz- 
mus, ahol terroristák jól szervezett 
csoportjai dolgoznak össze a világ 
minden pontján.(illuminati hong- 
kongban, a siluette párizsban, de ter- 
rorcsoport működik new-yorkban is) 
Ekkor lépünk be a UNATCO (United 
Nations Anti Terrorist Coalition) köte- 
lékébe, a bátyánk után, JC Denton né- 
ven. Kiképzésünk után azonnal a ter- 
roristák után küldenek minket, ahol 
több küldetést kell sikerrel megoldani. 
Természetesen ez nem egyszetű fel- 
adat. A pályák tele vannak csukott aj- 
tókkal, biztonsági kamerákkal, érzéke- 
lőkkel, automata gépfegyverekkel, 
őrökkel. Az RPG jelleg miatt skill kell 
szinte mindenhez. Amelyek természe- 
tesen fejleszthetőek. Minden feladat, 
küldetés, vagy egy új titkos hely felde- 
rítése tapasztalati pontot ér, mely be- 
váltható képességre, vagy meglévő ké- 
pesség fejlesztésére. Mindentudó ka- 
rakter természetesen nem létezik. 
Vehetünk/kaphatunkitalálhatunk ki- 
egészítőket a fegyvereinkhez, amellyel 
gyakorlatilag egyéni, a nekünk legin- 
kább megfelelő fegyverarzenált tud- 
juk kialakítani. Egy jól összerakott 
fegyvertár rendkívül hatékony. 
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Azonban azt nem árt észben tartani, 
hogy a játék erős Thief beütéssel bír, 
tehát a hentelés, akármilyen fegyver- 
tárral is tegyük, a biztos halált jelenti. 
Előnyben kell részesíteni a lopakodást 
és a gondolkodást. Főleg a gondolko- 
dásra lesz nagy szükség, hisz a párbe- 
szédek során a beszélgető partnereink 
olykor mint a vízfolyás úgy hazudnak, 
megpróbálnak tőrbe csalni, hamis in- 
formációt adnak. A számítógépek fel- 
törése, és a mailek elolvasása viszont 
nagy segítség a tisztább kép kialakítá- 
sához. Még bonyolultabbá teszi a játé- 
kot, hogy egy-egy cselekedetünk kihat 
a játék teljes menetére. Amint kezd ki- 
rajzolódni a történet, és Denton ügy- 
nök elkezd a dolgok mélyére látni, el- 
mosódik a határ a jó, és a rossz fiúk 
között. Kétségessé válik, hogy kit is 





szolgálunk, kik azok akiket terroristák- 
nak bélyegzünk, és mi a célunk. Ehhez 
azonban szigorúan titkos létesítmé- 
nyekbe kell belógni, sok kódot feltörni, 
és jó pár kulcsfigurával beszélgetni, no 
meg persze elvállalni a küldetéseiket. 
A játék legfőbb előnye, hogy a játékos 
aktív részese a cselekménynek. Min- 
den, (tényleg minden) rajta múlik, és 
szinte tapintható a felelősség, hogy mit 
is eredményezhet egy rossz döntés. 

A Deus Ex szinte új etalont teremtett 
azzal, hogy beutazhatjuk a világot. 
NewyYork és környéke, Hong-kong, 
Párizs, arizonai sivatag, 51-es körzet 

a főbb helyszínek, és a környező vidé- 
kük. Alattuk/bennük titkos kutató léte- 
sítmények, katonai raktárak, stb... 

És mi sem lehetne meggyőzőbb érv 

a hangulat mellett, hogy a játék végén 

















dönteni kell. Háromféle módon dönt- 
hetünk, teljesen szabadon: Világura- 
lom és új rend a földön, vagy szövet- 
ségre lépünk azzal aki megszervezte 
a világuralmat, esetleg ellenszegülünk, 
és ennek elpusztításával felszabadítjuk 
az emberiséget. Meglepő a játékmenet- 
ben (és az elején teljesen szokatlan), 
hogy gyakorlatilag mindenkivel be- 
szélgethetünk. Mindent megtehetünk. 
Kirabolhatunk egy boltot, újságot ol- 
vashatunk, ha látunk egy lámpát fel- 
kapcsolhatjuk, ihatunk a vízből ha víz- 
csapot látunk, lehúzhatjuk a WC-t, au- 
tomatából vehetünk üdítőt, és csokit, 
ehetünk, szó szerint sörözhetünk egy 
cigarettával, akár még kábítószert is fo- 
gyaszthatunk. A pályákon egyetlen 
olyan tárgy sincsen, amivel ne tud- 
nánk mit kezdeni. Valóban hihetetlen, 
hogy ilyen szabadság létezik egy játék- 
ban. És mindez Linuxon is mehet. 


A telepítése! 

A játéknak natív linuxos portja nin- 
csen sajnos. Anno a Lokigames kezdte 
el, de pont a DeusEx volt béta állapo- 
tú, amikor a cég csődöt jelentett. Így 

a natív kapu sosem készült el. Viszont 
tökéletesen működik a winex-es telepí- 
tője, ami semmi más, mint egy deusex 
winex-es konfiguráció, összedrótozva 
a Loki féle telepítő szettel. Ennél fogva 
(talán mondanom sem kell már, hisz 
mindenki tudja ezt) a telepítéshez 
kapcsoljuk ki az automount-ot. 

(az /etc/sysconfig/automount fájl törlé- 
se, aztán újraindítás. Az elindításához 
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csak újra létre kell hozni ezt a fájlt, és 
ismét újraindítani a gépet). A más 
rendszer alá készült DeusEx telepítő 
CD-re lesz még szükségünk, és termé- 
szetesen a winex-re. 

(2 htteNwww.transgaming.com) 

A DeusEx telepítőt 

a 5 http://liflg.sourceforge.net/ oldal- 
ról tudjuk lehúzni. Telepítése a telje- 
sen megszokott loki-módon történik. 
Külön öröm, hogy ha telepítve van 

a winex 3.x, és ezt a telepítőt lefuttat- 
juk, gond nélkül telepedik a játék, sőt 
mindenféle bütykölés nélkül fut is. 


Gépigény 

A játék gépigénye kicsit magasabb az 
emuláció miatt. De tényleg nem vé- 
szes, sőt meglepően jól fut. Egy 800-as 
duron processzoron, egy GeForce 2 
Titanium kártyával 1024x768-as fel- 
bontásban remekül megy a program. 
Akinek mégis gondja akadna vele, az 
természetesen csökkentheti a felbon- 
tás, vagy a textúra részletességet is. 
Jó játékot mindenkinek ezzel a kiváló 
programmal. 


. ] Dancsok , strogg" Zoltán 
(stroggomail.tvnet.hu) 
Jelenleg technikai szerkesz- 
tőként dolgozik a 
BME-OMIKK-nál, ahol oktat 

, is. Emellett egyetemi 
képzésben vesz részt, programozó matema- 
tikus szakon. Négy éve foglalkozik Linuxszal. 
Szabadidejében operációs rendszereket 
gyűjt és weblapot vezet. 


; 
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